Re: Switching to Java 1.5
Vincent, Am 09.06.2008 um 20:01 schrieb Vincent Hennebert: 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. Just saw that retroweaver contains verification against a 1.4 jdk if a classpath is given (e.g. a 1.4 jdk is installed). We could add this to the build path and require commiters to have a 1.4 jdk installed, and call verification during the build phase. This would actually be an advantage over the current situation, where 1.5 specific code (new methods) are sometimes added accidentally. Maybe we can start with just the verification an no retroweaving just yet? Thanks, Vincent Max
Re: Switching to Java 1.5
Max Berger wrote: Hi Max, Vincent, Am 09.06.2008 um 20:01 schrieb Vincent Hennebert: 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. Just saw that retroweaver contains verification against a 1.4 jdk if a classpath is given (e.g. a 1.4 jdk is installed). We could add this to the build path and require commiters to have a 1.4 jdk installed, and call verification during the build phase. This would actually be an advantage over the current situation, where 1.5 specific code (new methods) are sometimes added accidentally. Maybe we can start with just the verification an no retroweaving just yet? Yes I like that idea :) +1 from me. Chris
Re: Switching to Java 1.5
Just to clarify in case anyone isn't quite following what Vincent is proposing. All 1.4 deployment environments could remain as is without any change. For those that need 1.4 in their deployment environment, there would be provision in the FOP build script for the production of 1.4 compliant FOP jar file using a choice of either Retrotranslator or Retroweaver. This proposed change should only affect the development environments of developers working on the project (not users with 1.4 deployments). I propose that a user poll is launched. 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
Re: Switching to Java 1.5
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 HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Switching to Java 1.5
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 HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting Jeremias Maerki
Re: Switching to Java 1.5
Max Berger wrote: I have to disagreee. AAMOF, java 1.5 is ONLY supported on a select number of plattforms, mainly the ones Sun provides the JDK for (or is licensed). Well, gcj claims 1.5 compatibility and can be compiled on almost anything. My personal experience on a Debian AMD64 platform is that they still have a rather long list of problems to resolve, in particular I wasn't even able to build FOP trunk. J.Pietschmann
Re: Switching to Java 1.5
Hi all, I have attached a patch file which provides support for Retroweaver at compilation time in FOP's ant build script. You can grab the latest Retroweaver from http://downloads.sourceforge.net/retroweaver/retroweaver-2.0.5.zip. There is already quite some generics comments which could be easily uncommented in the FOP source code, so feel free to experiment. Adrian. 2008/6/5 Jess Holle [EMAIL PROTECTED]: I can't speak for the broader market but for my usages anything prior to Java 5 is dead wood and of no interest. As of October of this year anything prior to Java 5 will be officially unsupported by Sun except where you have a paid support contract with them (including that for Solaris). Add to that the fact that Java 1.4 is so limiting for so many things and Java 5 is supported on even the most odd ball platforms (except Java ME, but I don't see FOP on ME...) The Web Maestro wrote: +1 from me on a new poll for discussion. On Thu, Jun 5, 2008 at 11:56 AM, Jeremias Maerki [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +1 to being cautious about dropping support for Java 1.4 without consulting the user base first, i.e. +1 for another user poll, though I wouldn't do it before October. +1 to putting the users' desires above the developers' desires. +1 to moving to Java 1.5 when the time is right. -0.5 (no veto) to moving to Java 1.5 before Oct 2008. +1 to making experiments with Retroweaver (but please not in Trunk). On 05.06.2008 17:46:07 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 HennebertAnyware Technologieshttp://people.apache.org/~vhennebert http://people.apache.org/%7Evhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting Jeremias Maerki -- Adrian. Index: build.properties === --- build.properties (revision 662228) +++ build.properties (working copy) @@ -11,12 +11,16 @@ ## All Jars from the optional lib directory are added used for ## compilation and JUnit tests. Put your jars for additional ## dependencies and tools here. -# optional.lib.dir = /home/bart/java/lib +optional.lib.dir = /home/acumiskey/external-libs ## Checkstyle home directory. This is meant to be the top level
Re: Switching to Java 1.5
Just stumbled upon this... http://en.wikipedia.org/wiki/Comparison_of_backporting_tools Retrotranslator looks to have a more fully implemented feature set. Maybe we should try both. Adrian. Max Berger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Fop-devs, Jess Holle schrieb: As of October of this year anything prior to Java 5 will be officially unsupported by Sun except where you have a paid support contract with them (including that for Solaris). Add to that the fact that Java 1.4 is so limiting for so many things and Java 5 is supported on even the most odd ball platforms (except Java ME, but I don't see FOP on ME...) I have to disagreee. AAMOF, java 1.5 is ONLY supported on a select number of plattforms, mainly the ones Sun provides the JDK for (or is licensed). Those are: Solaris / Sparc Linux / Intel Windows / Intel. OS X / PowerPC + Intel (licensed) *BSD / Intel (through emulation layers) There are some be specific IBM jdks (on IBM plattforms), but I have no experience with these. That's it. Anyone using any other plattforms (such as Linux / Sparc, etc.) has to use either the blackdown JDK ( stuck at 1.4 ), or different JVMs, such as Jikes, Kaffee, etc., ALL OF THEM stuck at 1.4 as well or not fully compatible (such as gcj). I have Linux / Sparc as a work machine, and have been looking for a way to run 1.5 code for quite a while... OpenJDK being the most promising solution (although still not working). But as said in my earlier mail, retrotranslator / retroweaver works very well, and I would not mind the extra overhead. I just saw that retroweaver has some additional support for verification against an older JDK, this should definitely be used. Max -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFISOXf+Gr+4pk71JwRAtZ5AJ4wST3nP37EpwMStJpvaHK9+n077wCbBcuA cZ0fQtKPi9tXvX0wZDmveyk= =yPDf -END PGP SIGNATURE-
Re: Switching to Java 1.5
On Jun 5, 2008, at 19:26, Andreas Delmelle wrote: On Jun 5, 2008, at 17:46, Vincent Hennebert wrote: Hi Guys, I would like to raise this topic again: what about switching to Java 1.5 as a minimum requirement? No objection from me. +1 on moving forward with this in the trunk. Just to clarify my maybe overly enthusiastic response a bit: I'm under the impression that, with the mentioned backporting tools, even if we start using 1.5 features in the source, we can still quite easily deliver binaries that run on 1.4. As Jeremias mentioned, experiments with these tools should probably best be done in a separate branch for now, until we're sure that everything works as expected. OTOH, holding off too long on using 1.5 features, simply to be able to /compile/ FOP on 1.4 without any backporting, is a bit too cautious for my taste. I think we would mainly be holding ourselves back. It would be an entirely different matter if it was all-or- nothing... So my vote would still remain a +1 to move forward with this. Actually, Vincent's initial question is somewhat misleading. It does not seem a matter of having 1.5 as a minimum requirement. It's only on the level of the source that we would gradually move toward 1.5. For users of the binaries, nothing would change. They would still get their 1.4 compatible distribution. It's not as if we're dropping support for 1.4 entirely. Only those that want to play with the source code themselves and recompile will need access to a 1.5 JDK. In case we launch another user-poll, a question could also be added to check the positions on this matter: If the FOP-team were to decide to move forward to 1.5 for the source, but still distribute 1.4 binaries would that: a) keep you from using FOP? (most likely not) b) keep you from playing with the source code and contribute to FOP? (possibly, but far from certain) Cheers Andreas
Re: Switching to Java 1.5
Max Berger wrote: Jess Holle schrieb: As of October of this year anything prior to Java 5 will be officially unsupported by Sun except where you have a paid support contract with them (including that for Solaris). Add to that the fact that Java 1.4 is so limiting for so many things and Java 5 is supported on even the most odd ball platforms (except Java ME, but I don't see FOP on ME...) I have to disagreee. AAMOF, java 1.5 is ONLY supported on a select number of plattforms, mainly the ones Sun provides the JDK for (or is licensed). Those are: Solaris / Sparc Linux / Intel Windows / Intel. OS X / PowerPC + Intel (licensed) *BSD / Intel (through emulation layers) There are some be specific IBM jdks (on IBM plattforms), but I have no experience with these. That's it. Anyone using any other plattforms (such as Linux / Sparc, etc.) has to use either the blackdown JDK ( stuck at 1.4 ), or different JVMs, such as Jikes, Kaffee, etc., ALL OF THEM stuck at 1.4 as well or not fully compatible (such as gcj). I have Linux / Sparc as a work machine, and have been looking for a way to run 1.5 code for quite a while... OpenJDK being the most promising solution (although still not working). I guess I shouldn't have said even the most odd ball platforms but rather all but the most odd ball platforms. Java 5 runs on HPUX and AIX machines as well -- as well as on Solaris x86. When you've got Windows, Mac OS X, x86 Linux, Solaris, HPUX, and AIX covered, I'd say that's pretty good. The other platforms are, er, odd balls. The question is whether you hold everything else back for the odd balls that seem unlikely to progress beyond 1.4. -- Jess Holle
Re: Switching to Java 1.5
Jess Holle wrote: Max Berger wrote: Jess Holle schrieb: As of October of this year anything prior to Java 5 will be officially unsupported by Sun except where you have a paid support contract with them (including that for Solaris). Add to that the fact that Java 1.4 is so limiting for so many things and Java 5 is supported on even the most odd ball platforms (except Java ME, but I don't see FOP on ME...) I have to disagreee. AAMOF, java 1.5 is ONLY supported on a select number of plattforms, mainly the ones Sun provides the JDK for (or is licensed). Those are: Solaris / Sparc Linux / Intel Windows / Intel. OS X / PowerPC + Intel (licensed) *BSD / Intel (through emulation layers) There are some be specific IBM jdks (on IBM plattforms), but I have no experience with these. That's it. Anyone using any other plattforms (such as Linux / Sparc, etc.) has to use either the blackdown JDK ( stuck at 1.4 ), or different JVMs, such as Jikes, Kaffee, etc., ALL OF THEM stuck at 1.4 as well or not fully compatible (such as gcj). I have Linux / Sparc as a work machine, and have been looking for a way to run 1.5 code for quite a while... OpenJDK being the most promising solution (although still not working). I guess I shouldn't have said even the most odd ball platforms but rather all but the most odd ball platforms. Java 5 runs on HPUX and AIX machines as well -- as well as on Solaris x86. When you've got Windows, Mac OS X, x86 Linux, Solaris, HPUX, and AIX covered, I'd say that's pretty good. The other platforms are, er, odd balls. The question is whether you hold everything else back for the odd balls that seem unlikely to progress beyond 1.4. A view from the outside. With both HPUX and AIX, I imagine that there is another variable - which version of the OS supports 1.5. AIX versions don't come for the price of a Vista licence, and the same probably holds for HPUX. In addition, there may be minimum hardware requirements for upgrades. Talk to Chris about this. He has always been prominent in defending the FOP interests of his employers, and seems to know a bit about these issues. Wile we're on the topic... Concerning the issue of retaining 1.4 compatibility by hamstringing the use of 1.5 constructs: a truly, deeply, madly ridiculous idea. Go to 1.5, or don't. Simple. Don't complicate things with this notion of using generics, but nothing else. If (real) 1.5 is feasible, what about 1.6. There was a huge jump in the language itself between 1.4 and 1.5, which is why it has taken so long to wean the world off 1.4. There is not such leap between 1.5 and 1.6. The survey should canvas 1.5 and 1.6. I'd be curious to see how many systems support the first and not the second. The decision for FOP should be based, not on the end-of-life for a particular version, but on the pragmatic reality of 1.5 vs 1.6 support. That's the second glass of wine for the evening. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Switching to Java 1.5
Peter B. West wrote: Jess Holle wrote: Java 5 runs on HPUX and AIX machines as well -- as well as on Solaris x86. When you've got Windows, Mac OS X, x86 Linux, Solaris, HPUX, and AIX covered, I'd say that's pretty good. The other platforms are, er, odd balls. The question is whether you hold everything else back for the odd balls that seem unlikely to progress beyond 1.4. A view from the outside. With both HPUX and AIX, I imagine that there is another variable - which version of the OS supports 1.5. AIX versions don't come for the price of a Vista licence, and the same probably holds for HPUX. In addition, there may be minimum hardware requirements for upgrades. Talk to Chris about this. He has always been prominent in defending the FOP interests of his employers, and seems to know a bit about these issues. Wile we're on the topic... Concerning the issue of retaining 1.4 compatibility by hamstringing the use of 1.5 constructs: a truly, deeply, madly ridiculous idea. Go to 1.5, or don't. Simple. Don't complicate things with this notion of using generics, but nothing else. If (real) 1.5 is feasible, what about 1.6. There was a huge jump in the language itself between 1.4 and 1.5, which is why it has taken so long to wean the world off 1.4. There is not such leap between 1.5 and 1.6. The survey should canvas 1.5 and 1.6. I'd be curious to see how many systems support the first and not the second. Java 6 is supported on Windows, Mac OS X, x86 Linux, Solaris, HPUX, and AIX as well -- /but/ the Mac OS X support is limited to 64-bit Leopard only and the WebSphere does not support Java 6 yet and it seems like it will be a while until that changes. Java 6 has been out since December 2006, so everyone that is ever going to support it (except for WebSphere) likely does already. That said, Java 6 is not nearly so monumental of an improvement over Java 5 as Java 5 was over 1.4 -- at least in terms of features one would need to compile against. There are some really compelling features one might conditionally/reflectively use, e.g. in client apps, but I've not felt to hampered by building with Java 5 rather than 6 (as I have to) most of the time. The runtime performance, scalability, and manageability of Java 6 are much better than those of Java 5, however... -- Jess Holle
Switching to Java 1.5
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 HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Switching to Java 1.5
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
Re: Switching to Java 1.5
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
Re: Switching to Java 1.5
+1 to being cautious about dropping support for Java 1.4 without consulting the user base first, i.e. +1 for another user poll, though I wouldn't do it before October. +1 to putting the users' desires above the developers' desires. +1 to moving to Java 1.5 when the time is right. -0.5 (no veto) to moving to Java 1.5 before Oct 2008. +1 to making experiments with Retroweaver (but please not in Trunk). On 05.06.2008 17:46:07 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 HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting Jeremias Maerki
Re: Switching to Java 1.5
Vincent Hennebert wrote: Hi Guys, I would like to raise this topic again: what about switching to Java 1.5 as a minimum requirement? Hi Vincent, I'm happy to allow the use of generics in trunk code if retroweaver is used to maintain Java 1.4 support. I don't think the time is right to remove Java 1.4 compatibility altogether. Only a few weeks ago there were complaints on fop-user that the latest version couldn't be used because they were stuck on 1.3. 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. 14.3% is a big percentage of a user base to cut off. Even if its fallen to 5% thats still unacceptable in my opinion. I want to see FOP getting a bigger user base so the developer base increases. [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!”. +1 for a new Poll. snip/ Chris
Re: Switching to Java 1.5
+1 from me on a new poll for discussion. On Thu, Jun 5, 2008 at 11:56 AM, Jeremias Maerki [EMAIL PROTECTED] wrote: +1 to being cautious about dropping support for Java 1.4 without consulting the user base first, i.e. +1 for another user poll, though I wouldn't do it before October. +1 to putting the users' desires above the developers' desires. +1 to moving to Java 1.5 when the time is right. -0.5 (no veto) to moving to Java 1.5 before Oct 2008. +1 to making experiments with Retroweaver (but please not in Trunk). On 05.06.2008 17:46:07 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 HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting Jeremias Maerki -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://ourlil.com/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: Switching to Java 1.5
I can't speak for the broader market but for my usages anything prior to Java 5 is dead wood and of no interest. As of October of this year anything prior to Java 5 will be officially unsupported by Sun except where you have a paid support contract with them (including that for Solaris). Add to that the fact that Java 1.4 is so limiting for so many things and Java 5 is supported on even the most odd ball platforms (except Java ME, but I don't see FOP on ME...) The Web Maestro wrote: +1 from me on a new poll for discussion. On Thu, Jun 5, 2008 at 11:56 AM, Jeremias Maerki [EMAIL PROTECTED] wrote: +1 to being cautious about dropping support for Java 1.4 without consulting the user base first, i.e. +1 for another user poll, though I wouldn't do it before October. +1 to putting the users' desires above the developers' desires. +1 to moving to Java 1.5 when the time is right. -0.5 (no veto) to moving to Java 1.5 before Oct 2008. +1 to making experiments with Retroweaver (but please not in Trunk). On 05.06.2008 17:46:07 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 HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting Jeremias Maerki
