Community
Participate
Working Groups
[plan pri=3 est=4w/]
I have been looking into 1.5 support for EMF. As a first step I just compiled EMF with Java 1.5 and there are 3 compile errors. It seems that: compareTo no longer takes Object as its type, but rather the type of itself. (i.e. Double.compareTo is now compareTo(Double o) instead of compareTo(Object o)). This breaks EMF (actually org.eclipse.xsd) in three spots: org.eclipse.xsd.impl.type.XSDFloatType org.eclipse.xsd.impl.type.XSDDoubleType org.eclipse.xsd.impl.type.XSDDecimalType The compareValues in each of these requires a cast: return ((Float)value1).compareTo((Float)value2); // Line 36 return ((Double)value1).compareTo((Double)value2); // Line 36 return ((BigDecimal)value1).compareTo((BigDecimal)value2); // Line 42 I am wondering if we can get these changes in CVS. This *should* not break backwards compatibility since Objects should only be compared to other objects with the same type. Cheers, Ian
Current assesment suggests that introducing Java 5 features in EMF runtime will create backwards compatibility issues for some components in the Eclise 3.2 timeframe. Therefore, EMF team has no plans to introduce new Java 5 features in EMF for Eclipse 3.2. This bugzilla will be reconsidered in the next Eclipse version.
Does this mean that if we use EMF, we won't be able to run Eclipse 3.2 under the Java 5 runtime?
No. I know that people are definitely already using EMF with a Java 5 runtime already so there's no concern there. This just means that we won't be generating 5 targeted code and won't be templatizing things like EList and BasicEList until a subsequent release. If we templatized EList, we'd no longer be able to run in a 1.4 environment, so we need to take the step forward when most clients are prepared to leave 1.4 behind.
Another option is to make the target environment configurable in the .genmodel, i.e. keep support for generating 1.4 compatible code.
Gunnar, That's certainly possible, but this isn't nearly as straight forward as it is for the JDT to target a different JDK. The reason for the difference is that the JDT is not providing a runtime that will prop up the byte code it generates and the JDT is not necessarily itself using the same runtime as it targets. EMF, on the other hand, provides a runtime in addition to the JDT and that runtime will either be a 1.4 runtime or a 5.0 runtime but cannot be both. So while we could start using 5.0 to support a new runtime and we could add flags that would allow us to generate without exploiting 5.0, we'd be stuck somehow having to support multiple runtimes. Perhaps such a flag is useful anyway, and simply means that the generated code can be compiled against either the old or the new runtime. One way or the other, this will be a heck of a lot of work...
Besides support for Generics, are there any thoughts on how/if EMF could make use of the Java 5 annotation/metadata facilities? Perhaps this is better discussed in a different bugzilla report?
Doug, I've only thought briefly about that but we've really not had time to experiment with much of anything Java 5.0 related, so I'm not even in a great position to speculate. For example, I don't know how the annotation on the method in the interface relates to the annotation (if any) on the override in the implementation class?
There's an interesting thread in https://bugs.eclipse.org/bugs/show_bug.cgi?id=107783
Created attachment 43544 [details] Java 5 changes for common This is some initial experiments with Java 5. Don't assume that the final code will be similar to this one.
Created attachment 43545 [details] Some simple tests using Java 5 As before, don't assume it will be close to the final code.
What about other Java 1.5 support, things like Enums? I am currently working with the notification system and the types of notifications seem like the perfect spot for an enum (instead of an static integer list). Of course this will break backwards compatibility. Are these types of things worth investigating, or are we only concerned with supporting generics in our models? Or does it make sense to start creating separate bug reports for these topics? - ian
Ian, We'd like to achieve our end goal with a binary compatible runtime capable of running EMF code compiled with a runtime <= 2.2. This would give our clients maximum flexibility with the least amount of effort required on their part to move forward. We certainly want to give folks the option of generating a Java 5.0 enum verses a type-safe enum pattern. So for a notification's event type, the current design allows the API to be reused for other types of events, whereas a bounded enum would not allow such flexibility. I.e., such a change could leave clients in a bad state...
Created attachment 51566 [details] A full seemingly working templatization of org.eclipse.emf.common These changes to org.eclipse.emf.common are fully tested and everything downstream appears to continue working well with no source changes. The patch includes local compiler settings to help highlight any problems, such us uses of raw types. At this point, only unavoidable unchecked cast warnings remain. We could of course suppress these warnings, but one approach we might consider is the use of the "proposed" new utility class org.eclipse.emf.common.Cast with an "uncheckedCast" method that could be used everywhere an unchecked cast is currently needed. The benefit being that we'd know if we ever introduced an unchecked cast accidentally to some method that already contained another one and we could use Eclipse to easily find all unchecked casts by looking for calls to this method. Anyone have opinions on this approach?
Created attachment 51611 [details] Further changes in org.eclipse.emf.ecore I've started making changes in org.eclipse.emf.ecore. Some of those changes made me go back and revisit a few of the changes in org.eclipse.emf.common...
Created attachment 52409 [details] Updated patches against the lastest version of HEAD These are all the changes in org.eclipse.emf.common and org.eclipse.emf.ecore (in progress; not all done) as well as the changes to downstream plugins in EMF, XSD, UML2, and GMF needed to make these compile.
Created attachment 52910 [details] Updates for org.eclipse.emf.common and org.eclipse.emf.ecore Both org.eclipse.emf.common and org.eclipse.emf.ecore are effectively all done. Needs lots of review still, but the tests are passing...
Created attachment 53935 [details] More Updates The XMI plugin is done and the generator has a new "Compliance Level" option that will set to 5.0 or higher will generate 5.0 compliant code. The generator support is quite complete, i.e., not raw type warnings and enums are supported. It's not necessarily done in the prettiest way yet. It appears that the new real enum pattern is binary compatible with the old type safe pattern.
The changes for this are completed now.
Move to verified as per bug 206558.
