[cross-project-issues-dev] EMF 2.3 goes Generic

[Ed Merks <merks@xxxxxxxxxx>]

This week's EMF 2.3 build 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/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  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 M4!  (And before I
go on a much needed vacation.)

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:

   http://download.eclipse.org/tools/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 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).


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 969)