Hi
I'll see if I can get any sense from David today, since I'm
confused.
I develop with (have as my default JRE) 1.5 to ensure that I don't
accidentally use Java 6 library functions, and set compatibility
(Windows->Preferences) to 1.5 since as Adolfo also observes
sometimes some horrible class compatibility issues arise.
Yet the Platform page says 'In order to remain current, each Eclipse
Project release targets reasonably current operating environments.'
With Java 1.5 End Of Life in Oct 2009 Java 5 rather than 6 cannot be
compatible with the quoted goal.
Checking a few example platform and JDT 3.7 plugins there is a
variety of 1.3,1.4,1.5 JRE requirements; no obvious 1.6. Minimum JRE
seems to be a third design choice.
(Java 6 EOL is Jul 2012)
Perhaps we go for
Develop on 6, binary compatibility 5, minimum JRE 1.5 for Indigo.
Develop on 7, binary compatibility 5, minimum JRE 1.5 for Juno.
---
I don't think 3.4 execution is possible since;
EMF 2.6 introduced the invocationDelegates extension point and a
hard platform 3.6 dependency.
EMF 2.7 introduced the queryDelegates extension point and a hard
platform 3.7 dependency.
OCL uses these extension points and so has to propagate the EMF
dependency.
Oops, https://bugs.eclipse.org/bugs/show_bug.cgi?id=340748, OCL
3.1.0 ocl.ecore does not mandate EMF 2.7.
Regards
Ed
On 23/03/2011 04:18, Adolfo Sánchez-Barbudo Herrera wrote:
Ed, Axel, Laurent
Maybe I'm exposing stupid questions but I want to be sure we are
all speaking the same idiom, and please make any correction if
necessary...
- What is "Develope with Java6" ? I guess you mean you using a JRE
1.6 to run our Eclipse IDE ?. In this case, I'm also using Java
1.6 and I agree with axel the JVM 1.6 should increase our IDE
performance. No other side effects from the development point of
view (Well, perhaps "a side effect" is that you won't be able to
create Java 1.6 code unless you install other JREs: Window ->
Prferences -> Java -> Installed JREs)
- What is "with Java 5 compatibility" ? I guess you mean
configuring the IDE (specifically, JDT) so that we can work with
Java 1.5 code which:
1. can be compiled by a Java 1.5 compiler
2. the compiled byte code maybe executed by a JRE 1.5.
3. JDT helps us to deal with such a Java 1.5 code: Proper
warnings/errors in the editors, quick fixes suitable for the java
1.5 compiler, etc
This configuration is made doing the following : Window ->
Preferences -> Java -> Compiler -> Compiler compliance
level: 1.5
- Which compiler should we use, to build our code ?
1. Using a Java 1.5 compiler, will produce bytecode
executable by both JRE 1.5 and JRE 1.6.
2. Using a Java 1.6 compiler, will produce bytecode
executable only by JRE 1.6 (Sometimes, I've found problems (bad
class version execeptions) around Eclipse due to this situation).
So, taking into account that we set the J2SE-1.5 as the required
execution environment we must probably compile our code with a
Java 1.5 compiler, otherwise we are not complying with our own
specifications.
On the other hand, David commented that Indigo installation will
now require a JRE1.6 which may invite us to change our minimun
execution environment requirement. However, Laurent has exposed a
different use case which having such a Java 1.5 compatibily could
be useful (BTW Laurent, have you tested an Indigo Acceleo + OCL in
a Eclipse Ganymede ?¿? I'm very sceptical about this ;P ) ...
Furthermore, unless we need any specific need/advantage from Java
1.6, I'm also inclined to keep the Java 1.5 compatibility.
Best Regards,
Adolfo.
El 23/03/2011 9:17, Laurent Goubet escribió:
Hi,
I may be a little late to react to this, and I'll react more as
a commiter on M2T/Acceleo than as a commiter on MDT/OCL... But
I'll vote for OCL to "develop in Java 6 with Java 5
compatibility". Acceleo is widely used by clients that are still
on Java 5, using Eclipses that go sometimes all the way back to
3.4. OCL switching to use Java 6 only features would force us
(and other users of OCL-dependent tools) to drop all
compatibility options and switch to the latest Eclipse, latest
Java versions in order to use the latest Acceleo (and that's
something we've strived to avoid up till now).
Laurent
On 17/03/2011 20:14, Axel Uhl wrote:
I'm running my Eclipse on 6 since a long
time and only have a 5 installed for my OCL work as a target
environment. The one thing that finally would become possible
with 6 is @Override for interface methods (remember the
initial hick-ups with my code cause by me being on 6?). Other
than that, performance for 6 is much better, but we benefit
from that also by just *executing* on 6; I don't expect major
improvements just from *compiling* with 6 instead of 5.
Anyway, I'm all for 6/6 after Indigo.
Best,
-- Axel
On 3/17/2011 5:50 PM, Ed Willink wrote:
Hi
Recent cross-project-dev traffic highlighted a decision to
move to Java
6 only for aggregation builds.
Checking
http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments
it seems that Java 6 is preferred but other things may work.
Currently I develop with Java 5 with Java 5 compatibility. I
presume
this is what other team members do too.
Should we move to:
Develop with Java 6, with Java 5 compatibility
Develop with Java 6, with Java 6 compatibility
Should we move now or after Indigo?
NB. Our current 5 + 5 gives us compatibility warnings with a
JDT
reflective debug plugin.
I feel that if the platform expects perhaps only Java 6 to
be ok, we
should be using Java 6 for development.
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in
this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1498/3523 - Release Date:
03/22/11
|
