[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] EMF 3.0 will require Java 5.0

I will throw something else out for this discussion... The current (1.4-level) EMF-generated classes that ship with WTP are rather difficult to use for those adopters who are using java 5.0. The reason is that as soon as you access this api Eclipse floods you with hundreds of warnings regarding generics safety that you cannot do anything about short of explicitly suppressing these warnings. The problem with suppressing is that you loose warnings unrelated to EMF-generated class that you _do_ want to see. The bottom line is that it would be very beneficial for adopters who are using java 5.0 if WTP EMF-generated classes were generated using the new EMF 3.0 generics capabilities.

 

Regarding the “no 5.0 in common rule”, can we have an honest disclosure of where this requirement is coming from? What are the use cases? You can’t run WTP with just the common component. If there are certain adopters that need certain specific plugins to stay at 1.4 so that they can be re-used in non-WTP contexts, let’s enumerate those plugins instead of making a sweeping statement. If this is only a hypothetical requirement, let’s state that too so that everyone knows what we are dealing with.

 

- Konstantin

 


From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Tuesday, October 10, 2006 8:37 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] EMF 3.0 will require Java 5.0

 


Chuck, which pre-req is that?  JEM? XSD? If we needed a 1.4 version of those, we should say so.

But the key issue here isn't so much Java 5, or not, but what impact it would have on adopters code.
If adopters code doesn't have to change, we're good. If adopters code does have to change,
we need to look very closely at this issue and be prepared to use a 1.4 compatible version.

Oh, and do I need to say, we'll be looking to your teams Chuck to advise us on this. :)

We have stated already that for WTP as a whole we will require Java 5. But, "common" components
should stay compatible with 1.4, since those are the ones mostly likely used in other, smaller
OSGi environments. Exceptions to this "commons rule" will have to be approved by the PMC.

But even for non-common components we will specify an execution environment for each, to document
and "enforce" what is required, and then only move up to 1.5 execution environment if/when there is
some reason for it for that  bundle. That is, no capricious requirement on Java 5 ... there are likely good reasons
to use it in some plugins and we just want to capture what those reasons are.

Thanks








Chuck Bridgham/Raleigh/IBM@IBMUS
Sent by: wtp-dev-bounces@xxxxxxxxxxx

10/10/2006 10:16 AM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

To

"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

cc

Ed Merks <merks@xxxxxxxxxx>

Subject

Re: [wtp-dev] EMF 3.0 will require Java 5.0

 

 

 





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>

 

To

Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>, emf-dev@xxxxxxxxxxx

cc

 

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_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.