Slight change in release process for 8.5?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Slight change in release process for 8.5?

Rainer Jung-3
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?

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Slight change in release process for 8.5?

markt
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.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Slight change in release process for 8.5?

Rainer Jung-3
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.

Thanks and regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Slight change in release process for 8.5?

markt
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.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Slight change in release process for 8.5?

Konstantin Kolinko
2018-02-13 0:20 GMT+03:00 Mark Thomas <[hidden email]>:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]