accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlmar...@comcast.net
Subject Re: [OT] Can no longer obtain JDK6/JDK7 tarballs
Date Wed, 20 Jul 2016 11:41:07 GMT
Can't you use JDK8 and keep the source and target at 1.7? 

----- 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. 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message