thanks jvm builds, it's just the docker/jenkins stuff I'll need help on. Any volunteers?
On Wed, Apr 3, 2019 at 5:53 PM Aaron Fabbri <ajfab...@gmail.com> wrote: > +1 assuming we get the technical issues sorted. I'll give your patch a go > today. > > As Steve mentioned on the JIRA, unsupported JVM is called out as an > exception in the compatibility guidelines: > > "The JVM requirements will not change across point releases within the same > minor release except if the JVM version under question becomes unsupported" > > On Thu, Mar 28, 2019 at 3:39 PM Steve Loughran <ste...@cloudera.com.invalid > > > wrote: > > > I've just created a patch to update branch-2 to Java 8. Not sure what's > > going to break, but hopefully all problems can be done with some > selective > > changes. We know that Hadoop branch-2 builds and runs on Java 8, it being > > the java version we are already using for our branch-2 build and test > runs. > > > > It's time to move on; maintenance is getting harder and harder, as well > as > > more inconvenient. And while I know of clusters being deployed, they are, > > AFAIK, branch-2 on java 8 JVMs. This is just changing the language to > > reflect the reality. > > > > Before anyone asks, yes, our compatibility guidelines cover this; we had > > the same issue in the java 6 -> 7 move, remember? > > > > ---------- Forwarded message --------- > > From: Steve Loughran (JIRA) <j...@apache.org> > > Date: Thu, Mar 28, 2019 at 7:33 PM > > Subject: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java > > language version to 1.8 > > To: <common-dev@hadoop.apache.org> > > > > > > Steve Loughran created HADOOP-16219: > > --------------------------------------- > > > > Summary: Hadoop branch-2 to set java language version to 1.8 > > Key: HADOOP-16219 > > URL: https://issues.apache.org/jira/browse/HADOOP-16219 > > Project: Hadoop Common > > Issue Type: Improvement > > Components: build > > Affects Versions: 2.10.0 > > Reporter: Steve Loughran > > > > > > Java 7 is long EOL; having branch-2 require it is simply making the > release > > process a pain (we aren't building, testing, or releasing on java 7 JVMs > > any more, are we?). > > > > Staying on java 7 complicates backporting, JAR updates for CVEs (hello > > Guava!) &c are becoming impossible. > > > > Proposed: increment javac.version = 1.8 > > >
