Facility<Abc> ➝ Facility

We have reduced the signature of the Facility interface as shown in the title line. Reason was that it led to ugly code of the type Facility<? extends Facility<? extends ... häh?>>, and it was rather difficult to get that correct and typesafe.

The reason behind that was that Facility extended Identifiable, which is typed in the type of objects it identifies, e.g. Identifiable<Person>, leading to Id<Person>. Now in this case the container(s) are not at the level of Facility, but rather ActivityFacility or TransitStopFacility or ... , and we did not want to go back from the capability that you can identify the type of container from the Id.

So now now Facility is no longer implementing Identifiable. In most cases, this makes code simpler. However, there is code that operates at the level of Facility and is using the Id, e.g. for writing it out or for generating a key. Such things are now more complicated. Quite often, it seems that people actually meant ActivityFacility or TransitStopFacility, but programmed at the level of Facility since it was shorter to write. So they should maybe change.

If you are using Id at the level of facility, e.g. code of the type

if ( abc instanceof Identifiable ) { … ((Identifiable)abc).getId() … }

then please be aware that IDs may not be unique, i.e. you may have two facility objects having the same ID. Which, in fact, was also the case in the past.

Also see MATSIM-821.