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 . 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. > >  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 , 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. > >  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