Extensions are catalogued here: http://www.matsim.org/extensions 

An extension in this sense can be a Contrib, a project hosted externally, or even a part of org.matsim:matsim (pt, for example). The template allows providing a link to documentation. Contribs and parts of org.matsim:matsim should also link to their Javadoc.

We are not attempting not to have some space-time-representation of the traffic system which is shared between MobsimEngine instances (a "service network" or "infrastructure network" which may allow putting people on links or some such). NetsimNetwork is currently tied to the QNetsimEngine but accessed by other code. We may factor some of this out of QNetsimEngine to "legalize" this.

There was the question whether methods on Controler which allow to create service objects like TavelDisutility should be create-methods or getFactory-methods. In the meantime, all the Factory-getters and all the create-methods left on the Controler are going to disappear in favor of Dependency Injection.

MatsimConfigReader does not treat the string "null" as a special value anymore. This kind of interpretation is now up to each ConfigGroup.

Our top level containers provide Map views of their content. Population, for example, returns Map<Id<Person>, ? extends Person>. There is the argument that the only reason the wildcard is there was to make it compile-time-harder to add elements to this map, and that this was an abuse of Java syntax. There is no agreement on this. It is not even clear that providing a Map is the best idea at all. Hence, we will leave this in place until a distant-future possible major data API overhaul.

We encourage all cooperating institutions to do a playground-sweep: Delete playgrounds of your former team members who are no longer working on MATSim. For the future, we encourage institutions to share one playground among different team members. This reduces inter-playground dependencies, and it presumably reduces occurences of playgrounds which don't compile for a long time, because mroe people would be likely to notice.

We are not actively pursuing removing within-day replanning infrastructure from the core.

It should not, in general, be necessary to test for the 'presence' of a top-level container such as TransitSchedule. Ideally, the question should be resolved at configuration time: If I don't have the transit module in the loop, then I should also not have things in the loop which use the transit module. In terms of Guice:

We parameterize our modules by Config. It's OK for a module to decide based upon the Config if, or to which implementation, an interface is bound. Hence:

if (getConfig().scenario().isUseTransit()) {
    bind(TransitSchedule.class).toProvider(TransitScheduleProvider.class);
}

If I now later bind something which needs a TransitSchedule, it will not get injected null, but it will give a startup-time Exception.

Hence, when scenario.getTransitSchedule() throws an exception when there is no TransitSchedule, this approximates the above rather well, better than if it would return null.

It was suggested to always use boxed primitives (Integer, Boolean, ...) as member types in data objects, rather than primitives (int, bool, ...). This would allow null as a value, meaning "undefined". We could not agree that this is something which should be generally recommended. The discussion in this Issue contains a suggestion how to avoid the situation alltogether. And in Java 8, there will be java.util.Optional<T>, OptionalInt, etc.