Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <CALhtWkd4nr4Yx+jJzuLzzhG63Yb4wuhWG8QYUpiEjcCzm7Tsvw@mail.gmail.com>
References: <CAL5zq9aY+ftnQ8qpsvmN1801K5U4mzSQMYH9dv=2mPsF_KcSAg@mail.gmail.com>
 <251681951.8292671.1469014867182.JavaMail.zimbra@comcast.net>
 <CAGUtCHp=GJUw7jXeaaZ2SJ=ESxWSq0VVaH4AksLoduTtoAxhfQ@mail.gmail.com>
 <CALhtWkcY8fbg1a9iXjGxNXGUuDN9yc63oG=m=N5rqMhNkCAQKw@mail.gmail.com>
 <CAGUtCHqc_Qm2n=ODxno-cOdBReyknZjxKFqZ=Wj3YkGj4NwTMA@mail.gmail.com> <CALhtWkd4nr4Yx+jJzuLzzhG63Yb4wuhWG8QYUpiEjcCzm7Tsvw@mail.gmail.com>
From: Sean Busbey <busbey@cloudera.com>
Date: Wed, 20 Jul 2016 14:32:25 -0500
Message-ID: <CAGHyZ6JOaomD7EY=kECxH=6VgaF8KHutDykCBNCFGAnL+Upxxw@mail.gmail.com>
Subject: Re: [OT] Can no longer obtain JDK6/JDK7 tarballs
To: "dev@accumulo apache. org" <dev@accumulo.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Wed, 20 Jul 2016 19:33:00 -0000

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 <bimargulies@gmail.com> wrote:
> On Wed, Jul 20, 2016 at 10:41 AM, Keith Turner <keith@deenlo.com> wrote:
>> On Wed, Jul 20, 2016 at 9:34 AM, Benson Margulies <bimargulies@gmail.com>
>> 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 <keith@deenlo.com> wrote:
>>> > On Wed, Jul 20, 2016 at 7:41 AM, <dlmarion@comcast.net> 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" <ctubbsii@apache.org>
>>> >> To: "Accumulo Dev List" <dev@accumulo.apache.org>
>>> >> 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