Re: Switching to Java 1.5

[Max Berger]

Dear  Fop Devs,

I use retrotranslator for another project which has to run on specific  
version of scientfic Linux, where only Java 1.4 is installed.

There are two steps for using retrotranslator:
- Use NO 1.5 classpath features, just generics: Works very well with  
retrotranslator
- Use other 1.5 classpath features: Warning: AutoBoxing is part of  
this, since it uses the new Integer.valueOf() methods, which are not  
in 1.4. In this case, Fop would have to be distributed with the  
retrotranslator-runtime, which is 300kb

Retrotranlator-runtime contains many backports for common librarys,  
such as java.util.concurrent.

One thing is does not support (which made it unusable for other  
projects, such as JEuclid is the new high-plane unicode support in  
java 1.5. This would also be VERY interesting for fop, and i'd be a  
pitty not to use it).

Retroweaver and retrotranslator both provide similar functionality. I  
just chose retrotranslator because there is a maven plugin :)

I think in the long term this would be a good strategy for a soft move  
to 1.5, but I would like to ensure fop 0.96 works with 1.4

+1

Max

Am 05.06.2008 um 18:32 schrieb Adrian Cumiskey:

I would imagine that the availability of binary 1.4 compatibility  
should be enough for most users.

I don't see how there should be any problems so long as we continue  
to try and use the Java 1.4 libraries and the generics features of  
1.5.  I have tested out Retroweaver briefly in the past and it  
seemed to work well, but it would interesting to hear from anyone  
who has any hands on experience with using it.

+1 from me.

Adrian.

Vincent Hennebert wrote:
Hi Guys,
I would like to raise this topic again: what about switching to  
Java 1.5
as a minimum requirement?
The End of Life transition period for Java 1.4 will end on the 30th  
of
October 2008 [1]. The next version of FOP (after 0.95) will  
probably not
have been released by this time, so we could start using 1.5  
features in
the Trunk.
[1] http://java.sun.com/j2se/1.4.2/download.html
I don’t particularly expect any disagreement from a developer point  
of
vue (who doesn’t want to use 1.5 features?), so in the end this will
probably depend on the users’ reactions, but I thought I’d ask for
opinions here first.
According to the poll Jeremias made in October 2007 [2], only 14.3%  
of
the users would think it’s a bad idea to switch to 1.5. A year  
later the
percentage will probably have further decreased.
[2] http://wiki.apache.org/xmlgraphics/UserPollOct2007
I guess a new poll will still be necessary. Or we could base it on  
lazy
consensus: “If you still want Java 1.4 compatibility, speak up now!”.
Anyway, even if 1.4 compatibility is still considered to be required,
there are tools to convert 1.5 code into 1.4 compatible one. I’m  
mainly
thinking of Retroweaver:
http://retroweaver.sourceforge.net/
It’s BSD licensed, so IIC there wouldn’t be any problem to  
distribute it
with FOP. Obviously it would be an (optional) compile-time dependency
only. I haven’t personally tested it, but I’m told it’s working  
pretty
well and it seems to be well maintained. Of course I’d volunteer to
introduce it into the build system and see how it works. FWIW, it’s
based on the ASM library, that I’ve had the opportunity to play with
a few years ago, and what I can say is that it’s a really nice,  
strong,
lightweight, easy to use library for manipulating class files.
http://asm.objectweb.org/
Obviously we wouldn’t switch everything to 1.5 immediately. We  
would do
it progressively, when fixing bugs or implementing new features. So  
it
should be easy to check that the conversion is working properly by
running the testsuite on a 1.4 jvm, before every commit. Also, we  
could
restrain ourselves to features that are directly translatable to 1.4:
generics, enhanced for loop, autoboxing/unboxing. Most of all we  
could
stick to using methods from the Java standard library that are also
available in the 1.4 version (and, for instance, not use the new
concurrency package for now).
Just having the possibility to use generics would give us tremendous
benefits: simpler, cleaner, safer code, more easily understandable,  
more
easily maintainable, etc. I can’t wait anymore to use those features.
So, WDYT?
Thanks,
Vincent