Hi I asked an admin person to upgrade from his current 1.3.1_03 to 1.4.0_01 He said that's not possible because a lot of things running in 1.3.1 won't run when upgraded to 1.4.0. Can this be true because I find it a bit difficult to understand why something running in 1.3 won;t run anymore in 1.4 ???
... but not completely mistaken. There is software that runs in 1.3 but not in 1.4, and not necessarily because it's badly written. "A lot" is a gross exaggeration, and that is where he is mistaken, but it's there. A project I was involved in half a year ago used 1.3.1 because (a) Apache Batik didn't run under 1.4.1 at the time and (b) we had no end of trouble with the version of Xerces in 1.4.1. Certainly if there's quite a bit of Java software running, the admin is completely justified in his refusal to move to 1.4 without a compatibility test of the important software. YMMV, but don't count on it. - Peter [ January 07, 2003: Message edited by: Peter den Haan ]
We had in fact some problems moving our projects from 1.3 to 1.4. The biggest one was a class extending java.util.Vector and overwriting one of its methods in a way that on 1.4 an endless recursion occured (IIRC). But that was a very bad design decision anyway... :roll:
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss: We had in fact some problems moving our projects from 1.3 to 1.4. The biggest one was a class extending java.util.Vector and overwriting one of its methods in a way that on 1.4 an endless recursion occured (IIRC). But that was a very bad design decision anyway... :roll:
Another potential problem relates to the new assert keyword in 1.4. If you simply run the 1.4 VM on code containing variables or methods named assert without specifying that 1.4 asserts should not be used, you will run into BIG problems. Cheers Sam
<a href="http://www.samjdalton.com" target="_blank" rel="nofollow">Sam Dalton</a>,<br />Co-author of [http://www.amazon.com/exec/obidos/tg/detail/-/1590592255/qid=1068633302//ref=sr_8_xs_ap_i0_xgl14/104-4904002-9274339?v=glance&s=books&n=507846]Professional JSP 2.0[/URL] (October 2003)<br />Co-author of <a href="http://www.amazon.com/exec/obidos/ASIN/1861007701/ref=ase_electricporkchop" target="_blank" rel="nofollow">Professional SCWCD Certification</a><br />Co-author of <a href="http://www.amazon.com/exec/obidos/ASIN/186100561X/ref=ase_electricporkchop" target="_blank" rel="nofollow">Professional Java Servlets 2.3</a>
Another problem is the way image files (among others) are loaded from JAR files. I had a heck of a time with that when I converted trying to find the cause.
Peter den Haan
author
Ranch Hand
Joined: Apr 20, 2000
Posts: 3252
posted
0
Sam, is that true? My understanding is that the addition of the assert keyword (obviously) impacts source compatibility, but does not affect binary compatibility. On the JVM level I think it is legal for methods and variables to have names corresponding to reserved words. In fact, I'm using a Java bytecode obfuscator that works by, among other things, giving non-public variables and methods reserved names. - Peter
Originally posted by Peter den Haan: Sam, is that true? My understanding is that the addition of the assert keyword (obviously) impacts source compatibility, but does not affect binary compatibility. On the JVM level I think it is legal for methods and variables to have names corresponding to reserved words. In fact, I'm using a Java bytecode obfuscator that works by, among other things, giving non-public variables and methods reserved names. - Peter
Peter, Sorry you are correct, I meant to say that you would be unable to compile hte classes with a 1.4 compiler. Cheers Sam
0
