You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2009/03/29 08:35:25 UTC
Re: Retrotranslator - Java 5 Discussion Position Summary
Summary so far:
Please correct me if I'm wrong or missed anybody.
Which River release should we migrate to Java 5 language & API?
Those wanting Java 5 language & API features:
Dennis Reedy
Jim Waldo
Jonathan Costers
Greg Trasuk
Peter Firmstone
Niclas Hedhman
Dan Rollo
Those against using Retrotranslator and want to drop Java 1.4 runtime
support altogether: (please add names and brief comment)
Those happy for Java 1.4 bytecode compatibility release bundle to be
with maintained by using the Retrotranslator library at build time:
(When we transition to Java 5, building with JDK 1.4 will no longer be
supported)
Peter Firmstone
Patrick Wright
Sean Landis
Dan Rollo
I'm personally still concerned with dropping Java 1.4 runtime support
altogether, there are large companies around standardised on Java 1.4.
There's also a large install base of the JavaME CDC platform (Java SE
1.4.2 compatible), which includes BlueRay players, Digital TV's, Set top
boxes , photocopiers, the odd smart phone etc. Also the only Java
runtime on ARM is the JavaME CDC, some of these now have significant
memory and processing power and look like entering the netbook market.
I don't want to limit River if it can be helped. Anything without
enough resources can go the Surrogate route as Sean Landis has suggested.
Patrick Wright suggested: 'Perhaps the community can make a
project-level statement like, "as of release X, River will begin to use
Java 1.5 (or 6) APIs and language features." '
I'd also like to hear some more from Tim Blackman on the issue?
I have a concern that if we go the Java 5 and later route without Java
1.4 runtime support and later found that it was delaying adoption of
River we might find we've moved on too far to go back.
The cost of maintaining runtime compatibility with Retrotranslator:
1. Modifying build.xml to use Retrotranslator to create an additional
release bundle, "River X.X.X JAVA 1.4 Compatible release", generated by
the Ant build scripts specific to JRE 1.4
2. Running the regression tests against the River JRE 1.4 compatibility
release on JRE 1.4, can this be added as a separate optional run on the
regression test using Ant? The developer would probably need to set a
JAVA_HOME_JRE1.4 environment variable.
3. Solving bugs related to unsupported Java 5 or later features on
Retrotranslator and, I'm sure these and other bugs will arise from time
to time.
From the Retrotranslator project site:
How to use Retrotranslator from Apache Ant or Maven?
The distribution contains an Apache Ant <http://ant.apache.org/> task
|net.sf.retrotranslator.transformer.RetrotranslatorTask|. Every command
line <http://retrotranslator.sourceforge.net/#commandline> option can be
set using the corresponding attribute. In addition the source files can
be specified with nested |fileset|, |jarfileset|, and |dirset| elements
and the classpath
<http://retrotranslator.sourceforge.net/#option_classpath> can be set
with nested |classpath| elements or the |classpathref| attribute. The
source directories specified with |srcdir|, |dirset|, and the |dir|
attribute of |fileset| should contain the root package of the classes.
In case of warnings the build fails unless the value of the
|failonwarning| attribute is set to |false|. The following script can be
used to build one jar compatible with Java 1.4 and another one
compatible with Java 1.3.
<taskdef name="retrotranslator" classname="net.sf.retrotranslator.transformer.RetrotranslatorTask">
<classpath>
<fileset dir="../Retrotranslator-n.n.n-bin">
<include name="retrotranslator-transformer-n.n.n.jar" />
<include name="retrotranslator-runtime-n.n.n.jar" />
<include name="backport-util-concurrent-n.n.jar" />
</fileset>
</classpath>
</taskdef>
<retrotranslator target="1.4" destjar="build/application14.jar"
smart="true" verify="true" failonwarning="false">
<fileset dir="build/classes" includes="**/*.class" />
<jarfileset dir="build/lib" includes="**/*.jar" />
<classpath>
<fileset dir="../j2sdk1.4.2_17/jre/lib" includes="**/*.jar"/>
<fileset dir="../Retrotranslator-n.n.n-bin">
<include name="retrotranslator-runtime-n.n.n.jar" />
<include name="backport-util-concurrent-n.n.jar" />
</fileset>
<fileset dir="lib" includes="**/*.jar"/>
</classpath>
</retrotranslator>
<retrotranslator target="1.3" destjar="build/application13.jar"
smart="true" verify="true" failonwarning="false">
<fileset dir="build/classes" includes="**/*.class" />
<jarfileset dir="build/lib" includes="**/*.jar" />
<classpath>
<fileset dir="../jdk1.3.1_20/jre/lib" includes="**/*.jar"/>
<fileset dir="../Retrotranslator-n.n.n-bin">
<include name="retrotranslator-runtime13-n.n.n.jar" />
<include name="backport-util-concurrent-java12-n.n.jar" />
</fileset>
<fileset dir="lib" includes="**/*.jar"/>
</classpath>
</retrotranslator>
Re: Retrotranslator - Java 5 Discussion Position Summary
Posted by Sean Landis <se...@gmail.com>.
I was actually in the 1.5 camp.
On Sun, Mar 29, 2009 at 12:35 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Summary so far:
>
> Please correct me if I'm wrong or missed anybody.
>
> Which River release should we migrate to Java 5 language & API?
>
> Those wanting Java 5 language & API features:
>
> Dennis Reedy
> Jim Waldo
> Jonathan Costers
> Greg Trasuk
> Peter Firmstone
> Niclas Hedhman
> Dan Rollo
>
> Those against using Retrotranslator and want to drop Java 1.4 runtime
> support altogether: (please add names and brief comment)
>
>
>
>
> Those happy for Java 1.4 bytecode compatibility release bundle to be with
> maintained by using the Retrotranslator library at build time: (When we
> transition to Java 5, building with JDK 1.4 will no longer be supported)
>
> Peter Firmstone
> Patrick Wright
> Sean Landis
> Dan Rollo
>
> I'm personally still concerned with dropping Java 1.4 runtime support
> altogether, there are large companies around standardised on Java 1.4.
> There's also a large install base of the JavaME CDC platform (Java SE 1.4.2
> compatible), which includes BlueRay players, Digital TV's, Set top boxes ,
> photocopiers, the odd smart phone etc. Also the only Java runtime on ARM is
> the JavaME CDC, some of these now have significant memory and processing
> power and look like entering the netbook market. I don't want to limit
> River if it can be helped. Anything without enough resources can go the
> Surrogate route as Sean Landis has suggested.
>
> Patrick Wright suggested: 'Perhaps the community can make a project-level
> statement like, "as of release X, River will begin to use Java 1.5 (or 6)
> APIs and language features." '
>
> I'd also like to hear some more from Tim Blackman on the issue?
>
> I have a concern that if we go the Java 5 and later route without Java 1.4
> runtime support and later found that it was delaying adoption of River we
> might find we've moved on too far to go back.
>
> The cost of maintaining runtime compatibility with Retrotranslator:
>
> 1. Modifying build.xml to use Retrotranslator to create an additional
> release bundle, "River X.X.X JAVA 1.4 Compatible release", generated by the
> Ant build scripts specific to JRE 1.4
> 2. Running the regression tests against the River JRE 1.4 compatibility
> release on JRE 1.4, can this be added as a separate optional run on the
> regression test using Ant? The developer would probably need to set a
> JAVA_HOME_JRE1.4 environment variable.
> 3. Solving bugs related to unsupported Java 5 or later features on
> Retrotranslator and, I'm sure these and other bugs will arise from time to
> time.
>
> From the Retrotranslator project site:
>
>
> How to use Retrotranslator from Apache Ant or Maven?
>
> The distribution contains an Apache Ant <http://ant.apache.org/> task
> |net.sf.retrotranslator.transformer.RetrotranslatorTask|. Every command line
> <http://retrotranslator.sourceforge.net/#commandline> option can be set
> using the corresponding attribute. In addition the source files can be
> specified with nested |fileset|, |jarfileset|, and |dirset| elements and the
> classpath <http://retrotranslator.sourceforge.net/#option_classpath> can
> be set with nested |classpath| elements or the |classpathref| attribute. The
> source directories specified with |srcdir|, |dirset|, and the |dir|
> attribute of |fileset| should contain the root package of the classes. In
> case of warnings the build fails unless the value of the |failonwarning|
> attribute is set to |false|. The following script can be used to build one
> jar compatible with Java 1.4 and another one compatible with Java 1.3.
>
> <taskdef name="retrotranslator"
> classname="net.sf.retrotranslator.transformer.RetrotranslatorTask">
> <classpath>
> <fileset dir="../Retrotranslator-n.n.n-bin">
> <include name="retrotranslator-transformer-n.n.n.jar" />
> <include name="retrotranslator-runtime-n.n.n.jar" />
> <include name="backport-util-concurrent-n.n.jar" />
> </fileset>
> </classpath>
> </taskdef>
> <retrotranslator target="1.4" destjar="build/application14.jar"
> smart="true" verify="true" failonwarning="false">
> <fileset dir="build/classes" includes="**/*.class" />
> <jarfileset dir="build/lib" includes="**/*.jar" />
> <classpath>
> <fileset dir="../j2sdk1.4.2_17/jre/lib" includes="**/*.jar"/>
> <fileset dir="../Retrotranslator-n.n.n-bin">
> <include name="retrotranslator-runtime-n.n.n.jar" />
> <include name="backport-util-concurrent-n.n.jar" />
> </fileset>
> <fileset dir="lib" includes="**/*.jar"/>
> </classpath>
> </retrotranslator>
>
> <retrotranslator target="1.3" destjar="build/application13.jar"
> smart="true" verify="true" failonwarning="false">
> <fileset dir="build/classes" includes="**/*.class" />
> <jarfileset dir="build/lib" includes="**/*.jar" />
> <classpath>
> <fileset dir="../jdk1.3.1_20/jre/lib" includes="**/*.jar"/>
> <fileset dir="../Retrotranslator-n.n.n-bin">
> <include name="retrotranslator-runtime13-n.n.n.jar" />
> <include name="backport-util-concurrent-java12-n.n.jar" />
> </fileset>
> <fileset dir="lib" includes="**/*.jar"/>
> </classpath>
> </retrotranslator>
>
>
>
>
>
Re: Retrotranslator - Java 5 Discussion Position Summary
Posted by Peter Firmstone <ji...@zeus.net.au>.
Tim Blackman wrote:
> On Mar 29, 2009, at 2:35 AM, Peter Firmstone wrote:
>
>> I'd also like to hear some more from Tim Blackman on the issue?
>
> I don't have a strong opinion, but here are some thoughts.
>
> I have been developing (non-Jini/River) code with the Java 5 APIs for
> some time now, and have more recently switched to Java 6. There are
> definite advantages to switching. Parameterized types are nice, but
> not earth shaking. On the other hand, the java.util.concurrent
> package is very helpful.
>
> But I also ran into a case, just last week, that we had some code that
> we wanted to port to Java ME, which didn't support some Java 5
> features we were using. This is not Jini code, though, and I think it
> is probably a good argument that most people won't be running Jini on
> small devices. (There's a *very* long history behind this issue!)
>
> Still, it would be really too bad to prevent current users of Jini on
> JDK 1.4 from adopting River.
>
> I would imagine that Retrotranslator would only add support for
> language features, not the currency utilities. Of course, that
> probably doesn't matter unless Jini were to be updated to use these
> utilities.
>
> - Tim
>
Yep, it does support Concurrency Utilities, using a backport from Java
6. It also implements additional method parameters in classes in the
Java 5 API, there's a nice table summarising the features here, PS, it
uses ASM ; ) It supports enough of the Java 5 API to be interesting. I
figure that if we use it from the moment we go Java 5, we'll know what
additional Java 5 API features we want that aren't supported and add the
missing functionality to Retrotranslator. Until such a point in time
that it we are certain that we no longer need to support Java 1.4.
http://retrotranslator.sourceforge.net/
Re: Retrotranslator - Java 5 Discussion Position Summary
Posted by Tim Blackman <Ti...@sun.com>.
On Mar 29, 2009, at 2:35 AM, Peter Firmstone wrote:
> I'd also like to hear some more from Tim Blackman on the issue?
I don't have a strong opinion, but here are some thoughts.
I have been developing (non-Jini/River) code with the Java 5 APIs for
some time now, and have more recently switched to Java 6. There are
definite advantages to switching. Parameterized types are nice, but
not earth shaking. On the other hand, the java.util.concurrent
package is very helpful.
But I also ran into a case, just last week, that we had some code that
we wanted to port to Java ME, which didn't support some Java 5
features we were using. This is not Jini code, though, and I think it
is probably a good argument that most people won't be running Jini on
small devices. (There's a *very* long history behind this issue!)
Still, it would be really too bad to prevent current users of Jini on
JDK 1.4 from adopting River.
I would imagine that Retrotranslator would only add support for
language features, not the currency utilities. Of course, that
probably doesn't matter unless Jini were to be updated to use these
utilities.
- Tim