I just wanted to update folks on our
progress and what to expect from EMF for Europa. We are in the process
of changing our builds to use Java 5.0 so all our .class files will only
work in a 5.0 JVM. We will update every single plugin's MANIFEST.MF
to indicate that it requires Java 5.0 and we will increment the version
number to 3.0.0. For those downstream clients with hard coded upper
bounds, this will probably cause some pain; you might want to change the
upper bound on your EMF/XSD/SDO dependencies sooner rather than later.
contains patches for a complete templatization of org.eclipse.emf.common.
These changes have been tested and work with no changes to any downstream
plugins, so our first 3.0 build, or one shortly there after, will likely
contain these changes; we're still reviewing them in great detail, so comments
and feedback on the changes there would be most welcome. We'll be
particularly sensitive to any reports of binary incompatibility.
The next step will be templatizing org.eclipse.emf.ecore.
Firstly we will templatize the collection classes in org.eclipse.emf.ecore.util,
then the APIs and implementations in org.eclipse.emf.ecore.resource, and
eventually we will be regenerating the Ecore API itself to exploit all
the templatized collections. One issue I expect will come up is the
following. Resource.getContents will be changed to return EList<EObject>.
For clients who have suppressed EObject from their generated API,
this might result in a source incompatibility, i.e., they'll need to add
a cast to EObject when adding their objects to the resource's contents.
The underlying collection has always been backed by an EObject
array, so it must already be the case that anything you add must be compatible
with EObject at runtime. This source incompatibility will only be
a problem if you compile your source with Java 5.0 source compatibility
and hence you can avoid reacting to this change, or any of EMF's 3.0 changes,
by ensuring you build with 1.4 source compatibility.
If there are any questions, comments,
or concerns, now is a good time to raise them!
Note that in the interest of openness
and transparency we will be actively using the emf-dev mailing list for
development discussions like this.
905-413-3265 (t/l 969)