branch_4x source version 1.6

[Ryan Ernst <ry...@iernst.net>]

In my commit today for SOLR-5818, the backport to 4x had an issue with
using Long.compare, which was introduced in 1.7.  However, I was able to
compile and run the tests successfully on branch_4x before committing.
 Looking back, I see a lot of warning messages like:

"bootstrap class path not set in conjunction with -source 1.6"

Based on some cursory googling, it seems like that means it doesn't have
the 1.6 rt.jar, so it uses the 1.7 libs, but the 1.6 language rules.  That
would explain why Long.compare was "ok" according to javac.

I see common-build.xml is setting the bootclasspath, and that I believe I
can point the "bootjdk" property at 1.6.  But is there a way we can error
on this in the build, to prevent these kind of backport issues?

Thanks
Ryan

RE: branch_4x source version 1.6

[Uwe Schindler <uw...@thetaphi.de>]

Hi Ryan,

 

the whole thing was discussed quite often all around the world. We could use the same logic we have for Javadocs and set the bootclasspath, but I don’t think any developer will set this, because it makes configuring your build environment complicated.

For Javadocs we have the bootclasspath detection (-Dbootjdk=””) only for the case when we produce Javadocs for 4.x using a newer JDK (because they look nicer).

 

To fix the whole problem, it was already suggested by various people (including me) that Oracle should publish stripped down rt.jar versions (containing the public API only) on Maven central, but this is not done for legal reasons. See the ct.sym version in your $JAVA_HOME/lib dir, which is a zip file, only containing API definitions as class files in their META-INF/rt.jar dir. This file is produced with a tool during the build process of the JDK and contains all class files without method bodies. Javac is using that file (and not rt.jar) while compiling!!! Using that file from older JDK versions we could build against the correct symbol file, with IVY to generate some bootclasspath, but unfortunately it is not available in Maven Central. Another thing is to use a similar plugin like forbidden-apis, called “Animal Sniffer” (http://mojo.codehaus.org/animal-sniffer/).

 

For now we decided to let Jenkins complain, everything else is too expensive to implement and hard to setup for the committer. So nobody will kill you if you temporarily break the Jenkins build, which checks this by compiling with minimum Java version, too. Also we require that releases are done with the “official” JDK, so Lucene 4.x must be released by compiling with JDK 1.6. If this is not done, the release process will fail in the smoke tester.

 

Also using a newer javac with older source code does not help to prevent all problems, because javac is not fully backward compatible (although you use –source <version>). One famous example for this is Java 5 vs. Java 6. Java 5 forbids to use @Override on interface implementations (which is more correct in my opinion), but Java 1.6+’s javac does not complain about this, although used with –source 1.5. This are multiple reasons, why testing and compiling the code against the “official” minimum version is mandatory, otherwise we cannot guarantee that the whole release is compatible with the target platform.

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: uwe@thetaphi.de

 

From: Ryan Ernst [mailto:ryan@iernst.net] 
Sent: Saturday, March 08, 2014 5:29 AM
To: dev@lucene.apache.org
Subject: branch_4x source version 1.6

 

In my commit today for SOLR-5818, the backport to 4x had an issue with using Long.compare, which was introduced in 1.7.  However, I was able to compile and run the tests successfully on branch_4x before committing.  Looking back, I see a lot of warning messages like:

 

"bootstrap class path not set in conjunction with -source 1.6"

 

Based on some cursory googling, it seems like that means it doesn't have the 1.6 rt.jar, so it uses the 1.7 libs, but the 1.6 language rules.  That would explain why Long.compare was "ok" according to javac.

 

I see common-build.xml is setting the bootclasspath, and that I believe I can point the "bootjdk" property at 1.6.  But is there a way we can error on this in the build, to prevent these kind of backport issues?

 

Thanks

Ryan

Re: branch_4x source version 1.6

[Erick Erickson <er...@gmail.com>]

Hmmm, first warning you that all the nuances of different Java
versions really give me a headache...

I broke the build the same way a while ago, so now I issue the
command

export JAVA_HOME=`/usr/libexec/java_home -v 1.6`

before compiling any 4x branch.

So trying to compile this line:

if (Long.compare(5L, 20L) > 0) {}

failed. It succeeds if I:

export JAVA_HOME=`/usr/libexec/java_home -v 1.7`

This may not be  complete solution, but on my Mac
it keeps me from having to scramble upon occasion.

FWIW,
Erick

On Fri, Mar 7, 2014 at 11:29 PM, Ryan Ernst <ry...@iernst.net> wrote:
> In my commit today for SOLR-5818, the backport to 4x had an issue with using
> Long.compare, which was introduced in 1.7.  However, I was able to compile
> and run the tests successfully on branch_4x before committing.  Looking
> back, I see a lot of warning messages like:
>
> "bootstrap class path not set in conjunction with -source 1.6"
>
> Based on some cursory googling, it seems like that means it doesn't have the
> 1.6 rt.jar, so it uses the 1.7 libs, but the 1.6 language rules.  That would
> explain why Long.compare was "ok" according to javac.
>
> I see common-build.xml is setting the bootclasspath, and that I believe I
> can point the "bootjdk" property at 1.6.  But is there a way we can error on
> this in the build, to prevent these kind of backport issues?
>
> Thanks
> Ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org