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
>>>> 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.
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
(As said in many places. E.g.
An example of broken code caused by missing bootclasspath option when
compiling with Java 8:
2. Java 9 adds a new command-line option, --release
I suspect that recent commons daemon release (bundled with Tomcat 7)
also has a jdk version mismatch problem:
it is built with Java 7 , but targets Java 6 .
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
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org