To your specific problem, Christopher, Hadoop relies on Docker to install a correct build environment (per branch) and on branch-2 successfully uses oracle's JDK 7 and JDK 8 on Ubuntu Trusty, which I believe is still a modern OS.
https://github.com/apache/hadoop/blob/branch-2/dev-support/docker/Dockerfile i.e.: # Auto-accept the Oracle JDK license RUN echo oracle-java7-installer shared/accepted-oracle-license-v1-1 select true | sudo /usr/bin/debconf-set-selections RUN apt-get -q install --no-install-recommends -y oracle-java7-installer # Auto-accept the Oracle JDK license RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | sudo /usr/bin/debconf-set-selections RUN apt-get -q install --no-install-recommends -y oracle-java8-installer Perhaps there is a similar Docker based option for your OS? On Wed, Jul 20, 2016 at 2:32 PM, Sean Busbey <[email protected]> wrote: > 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 -- busbey
