2018-02-13 0:20 GMT+03:00 Mark Thomas <ma...@apache.org>: > On 12/02/18 20:54, Rainer Jung wrote: >> Am 12.02.2018 um 21:36 schrieb Mark Thomas: >>> On 12/02/18 19:20, Rainer Jung wrote: >>>> I noticed some differences between my own builds and the binary >>>> distributions for TC 8.5. More precisely the classes I build for the >>>> examples are not binary identical to the ones distributed with out >>>> binary distribution. >>>> >>>> Normally I would not worry too much about binary differences, but >>>> previous experience told me, that the class file contents are pretty >>>> stable. >>>> >>>> The deltas started with 8.5.27. For 8.5.24 my build is consistent, but >>>> for 8.5.27 there are small changes. Example: >>>> >>>> File webapps/examples/WEB-INF/classes/async/Async0.class has size 2899 >>>> Bytes in our binary distribution starting with 8.5.27, but size 2883 >>>> until 8.5.24 and for both versions when I build it myself. >>>> >>>> I wonder whether there was a change on Mark's packaging system eg. from >>>> Java 7 to Java 8 or Java 9 (of course still compiling for Java 7)? Is >>>> this guess correct or do we know any other reason? >>> >>> I use a dedicated VM for releases. Historically, I opted to do this >>> because I wanted to clean, consistent environment. These days it also >>> makes things easier as it allows my to do the release on Windows when my >>> main OS is Linux. >>> >>> Apart from the usual Microsoft updates (I keep the VM up to date with >>> patches) which I doubt are relevant here, the only other recent change >>> is an update to Java 8 Update 162. >>> >>> The Java update looks to be the most likely cause. A quick look in the >>> JAR manifests should confirm the Java version a release was built with. >> Ah, yes. And indeed: for example catalina.jar points at 1.7.0_80 for >> 8.5.24, at 1.8.0_144 for 8.5.27 and 1.8.0_162 for 8.5.28. So the change >> in the binary class observed by me was probably due to the change from >> Java 7 to Java 8 as the compilation environment (as I suspected). >> >> No worries, just wanted to understand it. > > I should probably go back to Java 7 for the 8.5.x release. I can't think > of a good reason why I changed.
+1 So 8.5.24 is OK, but binary releases of 8.5.27, 8.5.28, 8.5.28 are not guaranteed to run correctly on a Java 7 JRE. 1. The "source"/"target" options of javac should not be used without bootclasspath (As said in many places. E.g. [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2013-February/005743.html An example of broken code caused by missing bootclasspath option when compiling with Java 8: [2] http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html 2. Java 9 adds a new command-line option, --release http://openjdk.java.net/jeps/247 https://docs.oracle.com/javase/9/tools/javac.htm 3. BTW, I suspect that recent commons daemon release (bundled with Tomcat 7) also has a jdk version mismatch problem: it is built with Java 7 [3], but targets Java 6 [4]. But as there are not many lines of java code in commons-daemon, I hope that chances of really encountering a problem caused by misconfigured cross-compilation of those classes are slim. And if anyone encounters such problem, one could drop-in an older version of commons-daemon.jar [3] http://svn.apache.org/viewvc/commons/proper/daemon/trunk/HOWTO-RELEASE.txt?revision=1816117&view=markup#l22 [4] http://svn.apache.org/viewvc/commons/proper/daemon/trunk/pom.xml?revision=1820489&view=markup#l105 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
