View source for 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.

* http://www.eclipse.org/modeling/emf/downloads/?showAll=1&hlbuild=I200612071030#I200612071030

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  <tt>EList getFoo()</tt>
to <tt>EList<Foo> getFoo();</tt> you will find that you can no longer add something
typed as <tt>java.lang.Object</tt> to the list, you must add a <tt>Foo</tt>.  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 <tt>Foo</tt> in
order to correct the problem.  I expect that folks using
<tt>Resource.getContents().add(x)</tt>, which is now <tt>EList&lt;EObject&gt;</tt>, and have who
have suppressed <tt>EObject</tt> from their public APIs, will notice this issue.

If you want to try to generate 5.0 code, use the GenModel's <tt>Compliance
Level</tt> 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 [http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release#Milestones_and_Release_Candidates Milestone 4] is released! 

The reason for the <tt>Ecore</tt> changes it that we've extended it as illustrated
in the Javadoc to allow generics to be modeled directly in <tt>Ecore</tt> itself:

* http://download.eclipse.org/modeling/emf/emf/javadoc/2.3.0/org/eclipse/emf/ecore/package-summary.html#Generics

The general idea is that we introduce the notion of a generic type and any
existing reference to <tt>EClassifier</tt> that represents a type is augmented to
include a "generic" version. I.e., <tt>ETypedElement.eType</tt>,
<tt>EClass.eSuperTypes/eAllSuperTypes</tt>, and <tt>EOperation.eExceptions</tt> also have
<tt>ETypedElement.eGenericType</tt>,
<tt>EClass.eGenericSuperTypes/eAllGenericSuperTypes</tt>, and
<tt>EOperation.eGenericExceptions</tt>. 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
<tt>java.util.List</tt> or <tt>java.util.List&lt;java.lang.Integer&gt;</tt>. A generic type can
also reference a type parameter, i.e., it can represent, <tt>T</tt> or <tt>E</tt>. 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 <tt>Thing</tt>. A type
parameter can have bounds, i.e, it can represent <tt>&lt;T extends A & B&gt;</tt>, and
both <tt>EClassifiers</tt> and <tt>EOperations</tt> can have type parameters, i.e., it can
represent interface <tt>X&lt;T&gt; {}</tt> and <tt>&lt;T&gt; T foo()</tt>. A generic type has <tt>eRawType</tt>
that represents the erasure of the generic type and that erasure
determines, for example, the <tt>eType</tt> of the containing <tt>ETypedElement</tt>. And
finally <tt>EClassifier</tt> 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 <tt>EDataType</tt> for <tt>List&lt;Integer&gt;</tt> 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 [http://www.eclipse.org/emf/newsgroup-mailing-list.php 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:EMF_2.3_Generics | Talk]] pages very often.

[[Category:EMF]]
[[Category:Modeling]]
[[Category:Java]]