Good point Lawrence, it does look that
way - I'm assuming EMF codegen can "generate" both versions,
but the prereq plugins now require Java 5.
We'll need to plan accordingly
- Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
Lawrence Mandel <lmandel@xxxxxxxxxx> Sent by: wtp-dev-bounces@xxxxxxxxxxx
10/10/2006 01:43 AM
Please respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
To
wtp-dev@xxxxxxxxxxx
cc
Subject
[wtp-dev] EMF 3.0 will require Java
5.0
I may have missed any discussion around this but what effect will EMF requiring
Java 5 have on WTP? Will WTP now have to require Java 5?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
----- Forwarded by Lawrence Mandel/Toronto/IBM on 10/10/2006 01:39 AM -----
Ed Merks/Toronto/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
10/06/2006 03:16 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
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)
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev