[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cross-project-issues-dev] Europa and EMF 3.0
|
I for one am sorry to see this happen because EMF/XSD is
one of those quasi-platform projects that many other projects depend on. Your
decision to require a Java 5 VM will affect many others downstream. Java 5 and
Java 6 VM's can run Java 1.4 and earlier code just fine but without tricks
like Retroweaver the reverse is not true. People can disagree on this but I
don't think templatizing the API or using the odd Java 5-only API brings
enough value at this point. In fact many of the Platform components have gone
the other way, relying on smaller and smaller subsets of Java so they can be
deployed in as many limited environments as possible. Now if it were a new
project, or something that other projects didn't depend on, or something where
you would get a high value from a Java 5 feature like annotations, then that
would be different.
Just my 2cents from the peanut gallery,
--Ed
Hi, 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. Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=79768 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.
Ed Merks/Toronto/IBM@IBMCA
mailto:
merks@xxxxxxxxxx
905-413-3265 (t/l 969)
