RE: [cross-project-issues-dev] Java 1.5

[Ed Merks <merks@xxxxxxxxxx>]

Jeff,

The implications moving forward are
very clear and somewhat unfortunate, though perhaps not quite as black
and white as your statement.   Also, since a layering approach was
not applied in the JDK in order to templatize the Collection API, it's
not clear how that could be made to work.   We'd need two versions
of EList, BasicEList, EMap, BasicEMap, DelegatingListImpl, NotifyingListImpl,
EcoreEList, and so on, not to mention APIs such as Ecore itself.  Given
three developers doing all the development, the undertaking is already
a stretch.  In any event, the intent is that clients should be able
to compile with 1.4 compatibility and produce 1.4 .class files that will
run with an EMF 2.2 runtime on a 1.4 JVM, so clients will still have much
room to choose what's appropriate for them.  After all, using older
JVMs is how Java deals with this, so using older EMFs seems an analogous
approach; in necessary we can provide an EMF 2.3 (with only the bare minimum
changes needed to integrate with Eclipse 3.3).  It may also be possible
to compile the EMF 3.0 code base to produce 1.4 binaries so that we would
provide a stand-alone 1.4 runtime as well as a stand-alone 5.0 runtime.
 Isn't there a compiler option and JSR for compiling 5.0 source down
to 1.4 binaries?

We can discuss these issues at the Achitecture
Council meeting next week (just as these issues were discussed with all
the leads of the top level projects in Chicago a few months ago).


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

Jeff McAffer/Ottawa/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/06/2006 03:46 AM

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

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	RE: [cross-project-issues-dev] Java 1.5

Ed, 

So just to be clear, you are writing off a large number of EMF use cases/scenarios
as a result of this move.  EMF will not be usable on mobile or reduced
JRE clients.  Since there is an increasing (though still small) move
for people to use their components in several different scenarios, EMF
may well be ruled out as a candidate solution across the larger ranges
that need to accomodate the lowest common denominator.

I don't really know what you are doing but do wonder whether or not this
could be layered or structured such that you could get the Java5 use you
seek but do not force it on all EMF consumers. 

Meta-statement  the Europa team as a whole needs to try and set some
direction here.  For example, if BIRT uses EMF and EMF moves to Java
5, well BIRT is now ruled out of an additional range of usecases.

Jeff

Ed Merks/Toronto/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/05/2006 04:41 PM

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

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	RE: [cross-project-issues-dev] Java 1.5

Doug, 

EMF is in a bit of an odd position in that it provides and uses it own
runtime.  So unlike the JDT, which can target any JVM and hence can
support Java 5.0 without using Java 5.0 itself, EMF must target its own
runtime.   For example, org.eclipse.emf.common..util.EList which extends
java.util.List to add move methods needs to be templatized just as is List
itself and similarly the implementation class org.eclipse.emf.common.util.BasicEList
needs to be fully templatized.  As such, the org.eclipse.emf.common
plugin will depend on Java 5.0 and since all the rest of EMF depends on
this, all the rest of EMF will be bound by that decision; and of course
we'll want to regenerate the Ecore API to support Java 5.0.  So EMF
3.0 will absolutely not run on a 1.4 VM (which is why we are moving to
EMF 3.0 rather than EMF 2.3, even though we hope to provide a binary compatible
runtime capable of running 2.2-based code without recompilation).  It's
a huge undertaking for our tiny team, given that there is little experience
in this domain from which we can draw.  I'm finding that templatizing
collection APIs is shockingly complicated (even though using templatized
APIs is usually rather simple and nice). 


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

Doug Schaefer <DSchaefer@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/05/2006 10:27 AM

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

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	RE: [cross-project-issues-dev] Java 1.5

Thanks, Ed. I was thinking more about the runtime for your plug-ins. Will
EMF 3.0 run on a 1.4 VM? 
 
Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com

---

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ed Merks
Sent: Thursday, October 05, 2006 10:23 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Java 1.5
 

Doug, 

Supporting and exploiting Java 5.0 is the main development item for EMF
3.0.   We hope to make generating the 5.0 features optional and to
ensure that generated code can compile and run against the 2.2 EMF runtime
so that folks needing support for Java 1.4 will be able to achieve that.


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

Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/05/2006 10:14 AM

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

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	Re: [cross-project-issues-dev] Java 1.5

 

GMF is using 1.5 language features for this release.

- Rich


On 10/5/06 10:13 AM, "Doug Schaefer" <DSchaefer@xxxxxxx>
wrote:

Hey gang, I’m just wondering if any of the projects participating in Europa
are planning on dropping support for Java 1.4, i.e. are planning on using
Java 1.5 features.

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com

---

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


-- 
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev