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 . 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 Jeremias Maerki