You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by Steve Loughran <st...@cloudera.com.INVALID> on 2019/03/28 22:38:12 UTC
Fwd: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java
language version to 1.8
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) <ji...@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: <co...@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
Re: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java
language version to 1.8
Posted by Steve Loughran <st...@cloudera.com.INVALID>.
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 <aj...@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 <stevel@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) <ji...@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: <co...@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
> >
>
Re: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java
language version to 1.8
Posted by Steve Loughran <st...@cloudera.com.INVALID>.
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 <aj...@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 <stevel@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) <ji...@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: <co...@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
> >
>
Re: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java
language version to 1.8
Posted by Steve Loughran <st...@cloudera.com.INVALID>.
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 <aj...@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 <stevel@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) <ji...@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: <co...@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
> >
>
Re: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java
language version to 1.8
Posted by Aaron Fabbri <aj...@gmail.com>.
+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 <st...@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) <ji...@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: <co...@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
>
Re: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java
language version to 1.8
Posted by Aaron Fabbri <aj...@gmail.com>.
+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 <st...@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) <ji...@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: <co...@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
>
Re: [jira] [Created] (HADOOP-16219) Hadoop branch-2 to set java
language version to 1.8
Posted by Aaron Fabbri <aj...@gmail.com>.
+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 <st...@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) <ji...@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: <co...@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
>