matsim: immutable types?


Dear Marcel, Thibaut,

I am once more fighting with immutability. "Effective Java" recommends to favour immutability. I think that the potential advantages for parallel computing are evident.

However, in matsim we have always been fighting with this. The "population" was deliberately designed as an object-oriented database in memory, and as such was in fact designed around explicity mutability, and all efforts to make, say, routes immutable lead to awkward code.

I am now fighting with a similar situation within the Vehicles data hierarchy. The item of contention is vehicle.getType(), and if the returned VehicleType should be immutable. It was designed as such in the "freight" contrib. But not in the matsim core. I would like to have it consistent.

Consider the use case that, at some point, we want a 10% fuel efficiency improvements for some of our engine types . If vehicle types are immutable, we would need to replace the vehicle type for the affected vehicles:

for ( vehicle : vehicles ) {
if ( affectedType.equals( vehicle.getType() ) ) {
vehicle.setType( improvedType ) ; // (#)

The problem now comes if some code has kept a separate reference to the vehicleType. (Don't say that this does not happen; look at CarrierVehicleTypes.)

One thing that we could do would be to agree that "types" in the matsim scenario are immutable. This would imply that one should never keep references to such types, always go back to vehicle.getType() etc. when needed. But we would need that as agreement, otherwise it gets confusing to teach.

"Types" would be items of which we have a small number (such as vehicle types, activity types, road types, etc.), and which are referenced by our "physical" elements (persons, vehicles, signals, links, ...).

Do you have any thoughts on this?

Thanks and best wishes


PS: Some more material, maybe TL;DR

Evidently, one could say that vehicle itself should be immutable, i.e. line (#) should also not be possible, but then in use case we would need to replace the vehicle, and we have the same problem if someone keeps a reference to the vehicle. Overall, the problem will always be there, only pushed up or down. Still, I can imagine that someone caches the result of

vehicle.getType() ;

I cannot imagine that someone caches the result of

vehicle.getCapacity().getSeats() ;

MZ at some point said that this is just the way it is in Java: If you do

Person person = createPerson() ;
population.addPerson( person ) ;
person.addPlan(...) ;

we expect that we can keep the reference to person and can still work on it later.

Note that for "computation" (e.g. routing, mobsim), we already copy data from scenario to somewhere else, so those modules can construct their own data structures.


Clone<> to get started.
Look at<> for code examples.
Also see<> |<> |<> |<> .<>
+49 30 314 23308 (phone) +49 30 314 26269 (fax)
postal: TU Berlin Sekr. SG 12, Salzufer 17-19, 10587 Berlin
physical: building SG 4.1, room 305
[Created via e-mail received from: "Nagel, Kai, Prof. Dr." <>]




Thibaut Dubernet


Kai Nagel