Re: Moving to Java 1.5, retroweaving for 1.4
Dear Fop Devs, Peter B. West schrieb: Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit machines. Apple's commitment to Java has slackened off considerably. Peter Just for the mail archives: Snow Leopard (Mac OS X 10.6) includes Java 6 on 32-bit intel architectures [and was not yet released at the time of the original post]. Max -- http://max.berger.name/ OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700 signature.asc Description: OpenPGP digital signature
Re: Moving to Java 1.5, retroweaving for 1.4
On 03/09/2009, at 6:51 PM, Max Berger wrote: Dear Fop Devs, Peter B. West schrieb: Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit machines. Apple's commitment to Java has slackened off considerably. Peter Just for the mail archives: Snow Leopard (Mac OS X 10.6) includes Java 6 on 32-bit intel architectures [and was not yet released at the time of the original post]. Thanks Max. Very good news. Peter
Re: Moving to Java 1.5, retroweaving for 1.4
Hi Clay, The Web Maestro wrote: I agree about consistency w requirements... Perhaps one additional release req 1.4, then move to 1.5 for the next release. I don't have any real energy about whether the 1.0 should be 1.4 or 1.5, however... I do agree that there should be a significant version change signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)? If FOP is going to switch anyway, is there a compelling reason not to req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the jump)? Would that lock out a huge number of our audience? Would requiring 1.6 mean any significant performance or other benefit? I’d say it the other way round: I think that there is no compelling reason to switch to Java 1.6. Apart maybe from the internationalization area, the improvements made in that version are not likely to be that much of a benefit for FOP to justify the jump. Of course, that doesn’t prevent users from running FOP with a 1.6 JVM, and take advantage of the performance improvements made in that release. According to this thread the majority seems to go along with releasing a Java 1.4 compliant, 1.0 version. There would be a significant change in the number of the following release, along with a jump to Java 1.5 as a minimum requirement. That’s fine by me. I propose to launch the poll shortly after the release of 1.0. snip/ Vincent
Re: Moving to Java 1.5, retroweaving for 1.4
Vincent Hennebert wrote: Hi Vincent, I’d say it the other way round: I think that there is no compelling reason to switch to Java 1.6. Apart maybe from the internationalization area, the improvements made in that version are not likely to be that much of a benefit for FOP to justify the jump. Of course, that doesn’t prevent users from running FOP with a 1.6 JVM, and take advantage of the performance improvements made in that release. According to this thread the majority seems to go along with releasing a Java 1.4 compliant, 1.0 version. There would be a significant change in the number of the following release, along with a jump to Java 1.5 as a minimum requirement. That’s fine by me. I propose to launch the poll shortly after the release of 1.0. yes I agree with your summary above. Thanks, Chris
Re: Moving to Java 1.5, retroweaving for 1.4
On Tue, Aug 25, 2009 at 12:11:34PM +0100, Vincent Hennebert wrote: Hi Clay, The Web Maestro wrote: I agree about consistency w requirements... Perhaps one additional release req 1.4, then move to 1.5 for the next release. I don't have any real energy about whether the 1.0 should be 1.4 or 1.5, however... I do agree that there should be a significant version change signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)? If FOP is going to switch anyway, is there a compelling reason not to req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the jump)? Would that lock out a huge number of our audience? Would requiring 1.6 mean any significant performance or other benefit? According to this thread the majority seems to go along with releasing a Java 1.4 compliant, 1.0 version. There would be a significant change Agreed. in the number of the following release, along with a jump to Java 1.5 as a minimum requirement. That???s fine by me. Not agreed. There were two remarks about the version number. That part remains open. I propose to launch the poll shortly after the release of 1.0. Very well. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4
On 25.08.2009 20:38:19 Simon Pepping wrote: On Tue, Aug 25, 2009 at 12:11:34PM +0100, Vincent Hennebert wrote: Hi Clay, The Web Maestro wrote: I agree about consistency w requirements... Perhaps one additional release req 1.4, then move to 1.5 for the next release. I don't have any real energy about whether the 1.0 should be 1.4 or 1.5, however... I do agree that there should be a significant version change signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)? If FOP is going to switch anyway, is there a compelling reason not to req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the jump)? Would that lock out a huge number of our audience? Would requiring 1.6 mean any significant performance or other benefit? According to this thread the majority seems to go along with releasing a Java 1.4 compliant, 1.0 version. There would be a significant change Agreed. Agreed. in the number of the following release, along with a jump to Java 1.5 as a minimum requirement. That???s fine by me. Not agreed. There were two remarks about the version number. That part remains open. I don't think it's that important at the moment. Let's worry about the next release first. I propose to launch the poll shortly after the release of 1.0. Very well. Simon -- Simon Pepping home page: http://www.leverkruid.eu Jeremias Maerki
RE: Moving to Java 1.5, retroweaving for 1.4
Hi all, A few thoughts about Java 1.5 support and FOP version numbers. I suggest to keep the emblematic 1.0 for the full support of the XSLT-1.0 spec. I don't see any problem with FOP version hitting 0.99 or even 0.123 one day. Java 5 as minimum requirement sounds good to me (while another version with 1.4 sounds reasonable, too). But Java 6 is too high as minimum requirement. Java 5 is still the default JVM on Mac. Hope this helps, c. __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4362 (20090824) __ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.com
Re: Moving to Java 1.5, retroweaving for 1.4
On 24/08/2009, at 10:04 PM, Laurent Caillette wrote: Hi all, A few thoughts about Java 1.5 support and FOP version numbers. I suggest to keep the emblematic 1.0 for the full support of the XSLT-1.0 spec. I don't see any problem with FOP version hitting 0.99 or even 0.123 one day. Java 5 as minimum requirement sounds good to me (while another version with 1.4 sounds reasonable, too). But Java 6 is too high as minimum requirement. Java 5 is still the default JVM on Mac. Hope this helps, c. Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit machines. Apple's commitment to Java has slackened off considerably. Peter
Re: Moving to Java 1.5, retroweaving for 1.4
Dear Fop-Devs, since I am one of the people cited for moving forward to 1.5, I just want to throw my 2 cts in the mix: I would prefer a new release first, and then moving to 1.5. Rationale: 1) Retroweaving works, but there will be some bugs which will have to be ironed out and tested. The last release (0.95) has been done quite a long time back, and the next release will take even longer when a new feature (1.5) is added. 2) Since the 0.9x releases are test-releases towards 1.0, they should have the same features / requirements. 3) The next release (1.0.9x ? 1.9x?) could then depend on 1.5, whereas the 1.0 branch could stay on 1.4 As an example from another apache project: Maven moved from 2.1.0 to 2.2.0 rather than 2.1.x because they now require java 1.5 and did not want to make this a minor upgrade Max 2009/8/20 Simon Pepping spepp...@leverkruid.eu: On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote: Jeremias Maerki wrote: There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? Hi All, I'm not so against this idea 1 year further on but I still have concerns that we would force x% of users to stay on 0.95 if we do this. I agree with Jeremias' proposal to run a survey on fop-users for a couple of weeks to get some hard facts to help make an informed decision. Also, I think it is something that could wait until after the long promised 1.0 release. With the changing IPD feature being one of the last major features of 0.20.x missing from 0.9x that is now available we should consider doing the v1.0 release and then if the survey shows the number of 1.4 and earlier users to be very low then we should do the switch. I agree that we should proceed with a 1.0 release. I can also agree with releasing it compliant with Java 1.4. I note, however, that the methods I removed were several methods in class Character which are very useful in character handling, such as the method Character.toChars(int), which is the main method to convert an integer to an array of chars. That means that for Unicode values above 0x there is no good method to turn the value into a char[] or String. Also Characters.toLowerCase, toUpperCase, toTitleCase, getType, $UnicodeBlock. For a text handling application in 2009 that is a bit painful. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4
I agree about consistency w requirements... Perhaps one additional release req 1.4, then move to 1.5 for the next release. I don't have any real energy about whether the 1.0 should be 1.4 or 1.5, however... I do agree that there should be a significant version change signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)? If FOP is going to switch anyway, is there a compelling reason not to req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the jump)? Would that lock out a huge number of our audience? Would requiring 1.6 mean any significant performance or other benefit? Clay On 8/22/09, Max Berger m...@berger.name wrote: Dear Fop-Devs, since I am one of the people cited for moving forward to 1.5, I just want to throw my 2 cts in the mix: I would prefer a new release first, and then moving to 1.5. Rationale: 1) Retroweaving works, but there will be some bugs which will have to be ironed out and tested. The last release (0.95) has been done quite a long time back, and the next release will take even longer when a new feature (1.5) is added. 2) Since the 0.9x releases are test-releases towards 1.0, they should have the same features / requirements. 3) The next release (1.0.9x ? 1.9x?) could then depend on 1.5, whereas the 1.0 branch could stay on 1.4 As an example from another apache project: Maven moved from 2.1.0 to 2.2.0 rather than 2.1.x because they now require java 1.5 and did not want to make this a minor upgrade Max 2009/8/20 Simon Pepping spepp...@leverkruid.eu: On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote: Jeremias Maerki wrote: There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? Hi All, I'm not so against this idea 1 year further on but I still have concerns that we would force x% of users to stay on 0.95 if we do this. I agree with Jeremias' proposal to run a survey on fop-users for a couple of weeks to get some hard facts to help make an informed decision. Also, I think it is something that could wait until after the long promised 1.0 release. With the changing IPD feature being one of the last major features of 0.20.x missing from 0.9x that is now available we should consider doing the v1.0 release and then if the survey shows the number of 1.4 and earlier users to be very low then we should do the switch. I agree that we should proceed with a 1.0 release. I can also agree with releasing it compliant with Java 1.4. I note, however, that the methods I removed were several methods in class Character which are very useful in character handling, such as the method Character.toChars(int), which is the main method to convert an integer to an array of chars. That means that for Unicode values above 0x there is no good method to turn the value into a char[] or String. Also Characters.toLowerCase, toUpperCase, toTitleCase, getType, $UnicodeBlock. For a text handling application in 2009 that is a bit painful. Simon -- Simon Pepping home page: http://www.leverkruid.eu -- Regards, The Web Maestro -- the.webmaes...@gmail.com - http://ourlil.com/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? As for retroweaving: I've just set the necessary values in my build-local.properties and tried to compile the latest FOP Trunk with Java 1.5. The build failed in the retroweaver task: --- retro-avail: [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp [retroweaver] Processing 1775 classes [retroweaver] 1775 classes weaved. [retroweaver] Verifying 1775 classes [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isTitleCase/(I)Z, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toLowerCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method getType/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method of/(I)Ljava.lang.Character$UnicodeBlock;, Method not found in java.lang.Character$Unicod eBlock [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toUpperCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toTitleCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE$EncryptionFilter: unknown class javax.crypto.CipherOutputStream [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method doFinal/([B)[B, The class, javax.crypto.Cipher, could not be located: javax/crypto/Cipher [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.IllegalBlockSizeException, could not be located: javax/crypto/IllegalBlockSizeException [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.BadPaddingException, could not be loc ated: javax/crypto/BadPaddingException [retroweaver]
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
On 20/08/2009, at 7:41 PM, Jeremias Maerki wrote: There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? As for retroweaving: I've just set the necessary values in my build-local.properties and tried to compile the latest FOP Trunk with Java 1.5. The build failed in the retroweaver task: --- retro-avail: [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp [retroweaver] Processing 1775 classes [retroweaver] 1775 classes weaved. [retroweaver] Verifying 1775 classes [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/ Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/ Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isTitleCase/(I)Z, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toLowerCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method getType/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method of/(I)Ljava.lang.Character$UnicodeBlock;, Method not found in java.lang.Character$Unicod eBlock [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toUpperCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toTitleCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE$EncryptionFilter: unknown class javax.crypto.CipherOutputStream [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method doFinal/([B)[B, The class, javax.crypto.Cipher, could not be located: javax/crypto/Cipher [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.IllegalBlockSizeException, could not be located: javax/crypto/IllegalBlockSizeException [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class,
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
Thanks for the retroweaver report. I believe I removed all methods which are not Java 1.4 compliant. I tried to do a compilation in Java 1.4, but I failed with an UnsupportedClassVersionError, which I am not going to investigate now. So I could not test this myself. Simon On Thu, Aug 20, 2009 at 11:41:27AM +0200, Jeremias Maerki wrote: As for retroweaving: I've just set the necessary values in my build-local.properties and tried to compile the latest FOP Trunk with Java 1.5. The build failed in the retroweaver task: --- retro-avail: [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp [retroweaver] Processing 1775 classes [retroweaver] 1775 classes weaved. [retroweaver] Verifying 1775 classes [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ ... BUILD FAILED C:\Dev\FOP\main\trunk-clean2\build.xml:519: 28 warning(s) Jeremias Maerki wrote: Uhm, Simon, this change uses tons of Java 1.5 features. The build fails now on Java 1.4. OK if we revert until you've had a chance to revisit? -- Simon Pepping home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4
On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote: Jeremias Maerki wrote: There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? Hi All, I'm not so against this idea 1 year further on but I still have concerns that we would force x% of users to stay on 0.95 if we do this. I agree with Jeremias' proposal to run a survey on fop-users for a couple of weeks to get some hard facts to help make an informed decision. Also, I think it is something that could wait until after the long promised 1.0 release. With the changing IPD feature being one of the last major features of 0.20.x missing from 0.9x that is now available we should consider doing the v1.0 release and then if the survey shows the number of 1.4 and earlier users to be very low then we should do the switch. I agree that we should proceed with a 1.0 release. I can also agree with releasing it compliant with Java 1.4. I note, however, that the methods I removed were several methods in class Character which are very useful in character handling, such as the method Character.toChars(int), which is the main method to convert an integer to an array of chars. That means that for Unicode values above 0x there is no good method to turn the value into a char[] or String. Also Characters.toLowerCase, toUpperCase, toTitleCase, getType, $UnicodeBlock. For a text handling application in 2009 that is a bit painful. Simon -- Simon Pepping home page: http://www.leverkruid.eu
