Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EMF/EMF 2.3/Generics
As of December 7, 2006, EMF 2.3 includes the changes to templatize all of org.eclipse.emf.common, org.eclipse.emf.ecore, and org.eclipse.emf.ecore.xmi; the APIs for org.eclipse.xsd have also been regenerated to use generics.
We do not anticipate any binary compatibility problems from this with the exception the following:
Overrides of EPackageRegistryImpl.Delegator.put will find that putAll does not call their override and this can be worked around by also overriding putAll to be a copy of the method in the base class.
Extensions of many of the methods in BasicFeatureMap/DelegatingBasicFeatureMap will face similar issues; there is not much we can do, but no one should be doing this. Custom implementations of FeatureMap are not recommended.
Extensions of Ecore's ETypedElement, EClassifier, or anything below it (which we've told everyone not to do since 2002) will need to be recompiled to pick up of the shifted feature IDs. Also, if that model has not been regenerated using "Minimal Reflective Methods" provided in EMF 2.2, then it will have to be regenerated; please use that option when you regenerate so that you will not be forced to regenerate in the future.
If you compile your source with Java 1.4 source compatibility you should see no difference in the APIs and should not need to make any changes. If you compile your source with Java 5.0 source compatibility you may find there are a few simple and unavoidable source incompatibilities; we've only found two such issues outside of EMF, one in UML2 and one in GMF, both of which could be avoided by not using Java 5.0 or by making trivial changes such as adding casts or specializing the proper 5.0 method signatures. As an example, consider the implication of changing the method EList getFoo() to EList<Foo> getFoo(); you will find that you can no longer add something typed as java.lang.Object to the list, you must add a Foo. Of course under the covers EMF's lists have always been fail-fast (unlike Java's collection implementations which either fail statically or dynamic at the point of use as you fetch the data) so it should always be possible to cast to Foo in order to correct the problem. I expect that folks using Resource.getContents().add(x), which is now EList<EObject>, and have who have suppressed EObject from their public APIs, will notice this issue.
If you want to try to generate 5.0 code, use the GenModel's Compliance Level property and set it to 5.0. We still have merge problems with converting the old type safe enum pattern to a real enum; the good news is that a real enum we generate is binary compatible with the old pattern. If you see problems, let us know so we can fix them before Milestone 4 is released!
The reason for the Ecore changes it that we've extended it as illustrated in the Javadoc to allow generics to be modeled directly in Ecore itself:
The general idea is that we introduce the notion of a generic type and any existing reference to EClassifier that represents a type is augmented to include a "generic" version. I.e., ETypedElement.eType, EClass.eSuperTypes/eAllSuperTypes, and EOperation.eExceptions also have ETypedElement.eGenericType, EClass.eGenericSuperTypes/eAllGenericSuperTypes, and EOperation.eGenericExceptions. A generic type can reference a classifier and if that classifier has type parameters, it can have type arguments to represent the arguments for the parameterized type, i.e., it can represent java.util.List or java.util.List<java.lang.Integer>. A generic type can also reference a type parameter, i.e., it can represent, T or E. When used in the context of the type arguments of another generic type, a generic type can represent a wildcard (when none of the other properties are set) and that wildcard can optionally have either an upper or a lower bound, i.e., it can represent ?, ? extends Number, or ? super Thing. A type parameter can have bounds, i.e, it can represent <T extends A & B>, and both EClassifiers and EOperations can have type parameters, i.e., it can represent interface X<T> {} and <T> T foo(). A generic type has eRawType that represents the erasure of the generic type and that erasure determines, for example, the eType of the containing ETypedElement. And finally EClassifier is extended so that it can directly name/denote a parameterized type, not just a raw class (for classifiers that are used as wrappers), i.e., you can define an EDataType for List<Integer> and define a specialized serialization format for it.
If this all made sense the first time you read it, then we will make you an honorary member of the EMF team; you must answer a skill testing question to apply! If this made no sense to you, be sure to vote for and attend our long talk at EclipseCon: http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=3845. If you want to hear more about our basic Java experiences with this effort, be sure to vote for and attend this Java track long talk: http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=3812.
As I said, I'm very hopeful this transition will cause no serious problems, but if you do encounter serious problems, please let us know as soon as possible. If you have questions, please use the newsgroup since the most people will benefit from the answers posted there (and it's the best way to get a fast response from me).
If you have comments about this page, please post them to the newsgroup, as no one checks Talk pages very often.