With my suggesting to do the experiments on a branch I didn't mean a
longer-living branch. Really just an experiment to show how this works
and if it works and to give everyone a chance to do some testing.
Experiments can fail, too. You never know just from reading the shiny
marketing materiel if there are any hidden catches (especially in
complex environments: J2EE, web app, non-Sun JVMs etc.). If it works and
everyone is comfortable with it, a merge can be done quickly. That said
I'm happy with your summary.

On 09.06.2008 20:01:50 Vincent Hennebert wrote:
> Thanks everyone for your feedbacks. Let me summarize the thread:
> 
> - since within the development team itself there are already several
>   people who’d rather keep 1.4 compatibility, making a poll among users
>   just now is probably not necessary. The poll is likely to be made at
>   the end of October, that is at the same time End of Life is reached
>   for Java 1.4. For now we decide to keep (binary) 1.4 compatibility.
> - in the mean time, we try to plug Retroweaver/Retrotranslator/both in
>   the build system, and see how this is going. If it works well, then we
>   start to progressively introduce generics in the code, sticking to the
>   1.4 Standard Library (and, more generally, not using any 1.5 feature
>   that would be too difficult to translate back to 1.4).
> 
> There’s a point that I’d like to further discuss: why wouldn’t we
> implement Retroweaver/Retrotranslator in the Trunk? If we go the
> cautious route, that is if we run the test suite on a 1.4 jvm after each
> introduction of a 1.5 feature and before committing the change, I don’t
> see what’s the problem. Doing it in a branch more or less boils down to
> not doing it at all IMO... Or this would be a very short-lived branch
> (no more than a few weeks), just the time to test
> Retroweaver/translator.
> 
> Thanks,
> Vincent
> 
> 
> 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
> > 
> > 
> 
> -- 
> Vincent Hennebert                            Anyware Technologies
> http://people.apache.org/~vhennebert         http://www.anyware-tech.com
> Apache FOP Committer                         FOP Development/Consulting




Jeremias Maerki

Reply via email to