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: [email protected] From: Ryan Ernst [mailto:[email protected]] Sent: Saturday, March 08, 2014 5:29 AM To: [email protected] 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
