Skip to main content

[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'm certainly sympathetic to these concerns, which echo what Jeff has said in the other thread, and what I've heard many times already.  Unfortunately strictly respecting only these concerns also throws up a total road block for those clients who do wish to move forward.   The effects on EMF's generated API is quite pervasive in that it impacts all multi-valued features and it seems to me to be very significant that EList with a Javadoc comment indicating the element type is ActualType is far inferior to EList<ActualType> where it's absolutely explicit.  The JDK's approach has been to move forward and leave folks who need older VMs with older VMs to use, so it seems reasonable that EMF should take the same approach.   I.e., if EMF 3.0's generator can target an older EMF runtime, and we ensure that  the older EMF runtime (2.2) continues to function well as Eclipse itself continues to move forward (perhaps producing an EMF 2.3 if necessary), that seems to be the only way to try to make both camps of clients happy.  It's very frustrating not to be able to make everyone happy, but there's an old saying about that. ;-)

You're feedback is typically worth quite a bit for than 2 cents!!

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

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/06/2006 03:30 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
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,

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
Friday, October 06, 2006 3:16 PM
Cross project issues; emf-dev@xxxxxxxxxxx
[cross-project-issues-dev] Europa and EMF 3.0


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 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

Back to the top