We can also rely on nightly builds against jdk versions installed on ASF jenkins to catch incorrect api usage.
On Wed, Jul 20, 2016 at 9:45 AM, Benson Margulies <[email protected]> wrote: > On Wed, Jul 20, 2016 at 10:41 AM, Keith Turner <[email protected]> wrote: >> On Wed, Jul 20, 2016 at 9:34 AM, Benson Margulies <[email protected]> >> wrote: >> >>> Add the use of the animal sniffer plugin and/or the bootclasspath >>> option to the maven-compiler-plugin to force the use of only 1.7 apis. >>> >>> >> Thanks for the tip! Animal sniffer seems like it will solve the problem of >> building using JDK8. > > The bootclasspath is stronger, but takes more arrangements. You need a > way to get the 1.7 rt.jar in the picture without getting tangled up in > IP issues. > > > >> >> >>> >>> On Wed, Jul 20, 2016 at 9:13 AM, Keith Turner <[email protected]> wrote: >>> > On Wed, Jul 20, 2016 at 7:41 AM, <[email protected]> wrote: >>> > >>> >> Can't you use JDK8 and keep the source and target at 1.7? >>> >> >>> > >>> > Yes, but I think developers can accidentally use methods introduced in >>> > 1.8. If TreeMap.foo() only exists in Java 1.8 and someone uses it (in a >>> > 1.7 source compatible way), then the code will compile to 1.7 class >>> files. >>> > However, it will not actually run in 1.7 jre. >>> > >>> > I suspect most developers are using JDK8. So unless someone does a build >>> > with JDK 1.7 before release, these problems will go undetected. >>> > Christopher is trying to setup jenkins with multiple JDKs to do these >>> > builds. >>> > >>> > Is running jenkins on Centos 6 an option? Then maybe Centos6 has >>> OpenJDK6 >>> > and 7?? And can download Sun JDK8 for Centos 6. >>> > >>> > >>> >> ----- Original Message ----- >>> >> >>> >> From: "Christopher" <[email protected]> >>> >> To: "Accumulo Dev List" <[email protected]> >>> >> Sent: Tuesday, July 19, 2016 6:22:58 PM >>> >> Subject: [OT] Can no longer obtain JDK6/JDK7 tarballs >>> >> >>> >> I know we've discussed moving to JDK8 before, and we've moved the master >>> >> branch, which is expected to be 2.0.0. >>> >> >>> >> However, I'm trying to get the tarball for JDK7, so I can do >>> development on >>> >> older Accumulo branches while guaranteeing I don't do anything which >>> will >>> >> only work in JDK8. >>> >> >>> >> Unfortunately, OpenJDK does not provide tarballs to download, as far as >>> I >>> >> can tell. They work with downstream systems for packaging, but my OS >>> does >>> >> not package end-of-life (EOL) JDKs. >>> >> >>> >> So, I have to use the Oracle JDK tarball for JDK7. Unfortunately, Oracle >>> >> requires users to register to download EOL packages, and registration >>> >> requires users to provide a lot of details about themselves, their home >>> >> address, and their employment (required as part of the >>> registration/terms >>> >> of use). I'm unhappy and reluctant to disclose all that to Oracle (I'm >>> not >>> >> confident about their privacy practices). >>> >> >>> >> The alternative is to use an RPM for OpenJDK from another Linux distro, >>> but >>> >> that will probably not work outside the system it was designed for, and >>> >> would probably conflict with my installed JDK8 rpm. >>> >> >>> >> So, now it seems I'm screwed a bit, and can't do development in a "pure" >>> >> JDK7 JAVA_HOME on my modern OS. This is frustrating. Has anybody else >>> run >>> >> into this yet? What's your solution? >>> >> >>> >> I'm half tempted to suggest we require Java 8 for all future releases, >>> >> because of the difficulty of trying to guarantee support for older >>> versions >>> >> of Java when the EOL java versions are so increasingly difficult to >>> >> obtain... but I know that probably wouldn't go over very well. >>> >> >>> >> >>> -- busbey
