RE: [cross-project-issues-dev] Europa and EMF 3.0

[Ed Merks <merks@xxxxxxxxxx>]

Jeff,

Yes, we do intend to generate 2.2 compatible
code.
Such a feature would continue as long
as it's required by clients, which is probably forever.
I don't know all the draw backs yet.
 I suppose it's a little more complex to set the target platform rather
than directly use the running platform.  That's probably it though.
We will not necessarily be able to invest
significant development work in a 2.2+ stream of changes, so at best and
if necessary it will be like a maintenance stream.  We may need to
look to the community to help address any additional requirements on that
stream beyond the bare minimum that the existing team's resource can contain.

These types of notes, and of course our public plans, are my effort to
bring the community along.  This was also a topic of discussion at
the Architecture meeting in Chicago.   I just don't want to be put
in the position of having to advocate the virtues of Java 5.0 itself as
a motivator for moving forward because I'm likely to end up pointing out
some of my own concerns about why the language was changed in such dramatically
complex way.  But most of our respective organizations voted in favor
of this drastic change although I'm not sure that was ever well socialized.
 Our primary reason for moving forward is that the language has moved
forward and there are a growing set of clients who want to move forward
along with it.  Without us doing our part, there will be no forward
movement for anyone.   I don't think it's so clear that folks are
losing anything more than we all lost when the JDKs stopped going to 1.4.x
and went to 5.0 instead.  Perhaps one example is the use of EMF by
Apache's Tuscany project which expects to be able to generate 5.0-based
SDO APIs.   It will be another year before EMF is available as a release
which means it will probably be almost two years before this shows up in
commercial products; it seems not a stretch of the imagination to suppose
that two years from now, commercial products will have a large client base
expecting and even demanding rich support for Java 5.0.
 

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/07/2006 04:22 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] Europa and EMF 3.0

Hey Ed, 

One of your comments made me wonder a few things...
        "If EMF 3.0's generator can target an
older EMF runtime, ..." 

- Will EMF 3.0 be able to generate EMF 2.2/2.3 compatibile code?
- Will this continue into the future? 
- What will be the drawbacks of targeting the old runtime vs the new?
- Will the EMF 2.x runtime be kept uptodate with new features added to
EMF 3.x? 

I understand and sympathize with your situation however you do need to
bring the community along with you.  To that end, would it be possible
to write up the benefits of this move?  I am not all that familiar
with what EMF users need/want from its API but since it is clear people
are losing something here, it would be good if they clearly understood
what they are gaining.  Perhaps illustrations of actual users who
have been asking for this or meeting challenges because of the current
structure. 

Jeff

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

10/06/2006 10:31 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] Europa and EMF 3.0

Ed, 

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. ;-) 

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

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

---

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


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