You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Colin McCabe <cm...@apache.org> on 2016/12/07 01:10:27 UTC

Re: any plans to switch to java 8?

Interestingly, Hadoop 3.x will require Java 8 or later.

From http://hadoop.apache.org/docs/r3.0.0-alpha1/
> Minimum required Java version increased from Java 7 to Java 8
> All Hadoop JARs are now compiled targeting a runtime version of Java 8. Users still
> using Java 7 or below must upgrade to Java 8.

Of course, there are still many people using Hadoop 2.x and
distributions derived from it, and will be for a while.

best,
Colin


On Mon, Nov 28, 2016, at 11:21, Ismael Juma wrote:
> By supporting two Java versions, I mean supporting the two most recent
> ones. So, we'd only drop support for Java 7 after Java 9 is released, but
> no sooner (independently of how old or unsupported a particular version
> is). An alternative approach is to drop support a defined amount of time
> after a particular version is EOL'd.
> 
> With respect to the question about the cost of supporting multiple Java
> versions: it is OK to compile with the oldest version, but we definitely
> need to run the unit, integration, system and performance tests with all
> supported versions. The Java team strives to maintain compatibility, but
> regressions and behaviour differences are not uncommon across major
> releases (and sometimes update releases). Projects like Lucene are very
> good at hitting JIT bugs and they actually test against JDK EA snapshot
> builds in the hope of triggering them before a stable release.
> 
> Ismael
> 
> On Mon, Nov 28, 2016 at 6:39 PM, radai <ra...@gmail.com>
> wrote:
> 
> > i dont completely understand the meaning behind supporting 2 java versions.
> > given java's pretty good about backwards compatibility if you build against
> > the oldest JDK you support (say 8) it should run on anything newer (say 9).
> > what am i missing?
> >
> > On Mon, Nov 28, 2016 at 4:06 AM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > I think there are 3 main points that can be taken from that discussion
> > with
> > > regards to the timing:
> > >
> > > 1. We should do the switch no earlier than Kafka's next major version
> > bump
> > > (i.e. 0.11.0.0 at this point)
> > > 2. Some would prefer to support two Java versions, so we'd have to wait
> > > until Kafka's next major version bump _after_ Java 9 is released. Java 9
> > is
> > > currently scheduled to be released in July 2017. I like the guideline of
> > > supporting two Java versions at a time, but multiple delays to Java 8
> > and 9
> > > combined with huge improvements in Java 8 could provide the basis for an
> > > exception.
> > > 3. Some would prefer the clients jar to support Java 7 for longer as
> > there
> > > are cases where it is hard to upgrade all clients to use Java 8 (maybe
> > they
> > > run in an older App Server that only supports Java 7, for example).
> > >
> > > It seems like 1 is a hard requirement while 2 and 3 are less so. Given
> > > that, I was planning to restart the conversation when we have a plan to
> > > bump Kafka's major version (a message format change would quality
> > > typically).
> > >
> > > Ismael
> > >
> > > On Thu, Nov 10, 2016 at 7:03 PM, Joel Koshy <jj...@gmail.com> wrote:
> > >
> > > > http://markmail.org/message/gnrn5ccql7a2pmc5
> > > > We can bump that up to revisit the discussion. That thread didn't have
> > > any
> > > > closure, but has a lot of background information.
> > > >
> > > > On Thu, Nov 10, 2016 at 10:37 AM, Sean McCauliff <
> > > sean.mccauliff@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Wait for JDK 9 which is supposed to be 4-5 months from now?
> > > > >
> > > > > Sean
> > > > >
> > > > > On Thu, Nov 10, 2016 at 10:23 AM, radai <ra...@gmail.com>
> > > > > wrote:
> > > > > > with java 7 being EOL'ed for more than a year and a half now (apr
> > > 2015,
> > > > > see
> > > > > > http://www.oracle.com/technetwork/java/eol-135779.html) i was
> > > > wondering
> > > > > if
> > > > > > there's an official plan/timetable for transitioning the kafka
> > > codebase
> > > > > > over to java 8?
> > > > >
> > > >
> > >
> >

Re: any plans to switch to java 8?

Posted by Ismael Juma <is...@juma.me.uk>.
Hi Colin,

Indeed, Hadoop was one of a few projects I mentioned in the original
thread. When is Hadoop 3 expected to be stable?

Examples are Cassandra[4], Lucene[5], Akka[6], Hadoop 3[7],
> Jetty[8], Eclipse[9], IntelliJ[10] and many others[11]. Even Android will
> support Java 8 in the next version (although it will take a while before
> most phones will use that version sadly).
> ...

[4] https://github.com/apache/cassandra/blob/trunk/README.asc
> [5] https://lucene.apache.org/#highlights-of-this-lucene-release-include
> [6] http://akka.io/news/2015/09/30/akka-2.4.0-released.html
> [7] https://issues.apache.org/jira/browse/HADOOP-11858
> [8] https://webtide.com/jetty-9-3-features/
> [9] http://markmail.org/message/l7s276y3xkga2eqf
> [10]
>
> https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under
> [11] http://markmail.org/message/l7s276y3xkga2eqf


Ismael

On Wed, Dec 7, 2016 at 1:10 AM, Colin McCabe <cm...@apache.org> wrote:

> Interestingly, Hadoop 3.x will require Java 8 or later.
>
> From http://hadoop.apache.org/docs/r3.0.0-alpha1/
> > Minimum required Java version increased from Java 7 to Java 8
> > All Hadoop JARs are now compiled targeting a runtime version of Java 8.
> Users still
> > using Java 7 or below must upgrade to Java 8.
>
> Of course, there are still many people using Hadoop 2.x and
> distributions derived from it, and will be for a while.
>
> best,
> Colin
>
>
> On Mon, Nov 28, 2016, at 11:21, Ismael Juma wrote:
> > By supporting two Java versions, I mean supporting the two most recent
> > ones. So, we'd only drop support for Java 7 after Java 9 is released, but
> > no sooner (independently of how old or unsupported a particular version
> > is). An alternative approach is to drop support a defined amount of time
> > after a particular version is EOL'd.
> >
> > With respect to the question about the cost of supporting multiple Java
> > versions: it is OK to compile with the oldest version, but we definitely
> > need to run the unit, integration, system and performance tests with all
> > supported versions. The Java team strives to maintain compatibility, but
> > regressions and behaviour differences are not uncommon across major
> > releases (and sometimes update releases). Projects like Lucene are very
> > good at hitting JIT bugs and they actually test against JDK EA snapshot
> > builds in the hope of triggering them before a stable release.
> >
> > Ismael
> >
> > On Mon, Nov 28, 2016 at 6:39 PM, radai <ra...@gmail.com>
> > wrote:
> >
> > > i dont completely understand the meaning behind supporting 2 java
> versions.
> > > given java's pretty good about backwards compatibility if you build
> against
> > > the oldest JDK you support (say 8) it should run on anything newer
> (say 9).
> > > what am i missing?
> > >
> > > On Mon, Nov 28, 2016 at 4:06 AM, Ismael Juma <is...@juma.me.uk>
> wrote:
> > >
> > > > I think there are 3 main points that can be taken from that
> discussion
> > > with
> > > > regards to the timing:
> > > >
> > > > 1. We should do the switch no earlier than Kafka's next major version
> > > bump
> > > > (i.e. 0.11.0.0 at this point)
> > > > 2. Some would prefer to support two Java versions, so we'd have to
> wait
> > > > until Kafka's next major version bump _after_ Java 9 is released.
> Java 9
> > > is
> > > > currently scheduled to be released in July 2017. I like the
> guideline of
> > > > supporting two Java versions at a time, but multiple delays to Java 8
> > > and 9
> > > > combined with huge improvements in Java 8 could provide the basis
> for an
> > > > exception.
> > > > 3. Some would prefer the clients jar to support Java 7 for longer as
> > > there
> > > > are cases where it is hard to upgrade all clients to use Java 8
> (maybe
> > > they
> > > > run in an older App Server that only supports Java 7, for example).
> > > >
> > > > It seems like 1 is a hard requirement while 2 and 3 are less so.
> Given
> > > > that, I was planning to restart the conversation when we have a plan
> to
> > > > bump Kafka's major version (a message format change would quality
> > > > typically).
> > > >
> > > > Ismael
> > > >
> > > > On Thu, Nov 10, 2016 at 7:03 PM, Joel Koshy <jj...@gmail.com>
> wrote:
> > > >
> > > > > http://markmail.org/message/gnrn5ccql7a2pmc5
> > > > > We can bump that up to revisit the discussion. That thread didn't
> have
> > > > any
> > > > > closure, but has a lot of background information.
> > > > >
> > > > > On Thu, Nov 10, 2016 at 10:37 AM, Sean McCauliff <
> > > > sean.mccauliff@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Wait for JDK 9 which is supposed to be 4-5 months from now?
> > > > > >
> > > > > > Sean
> > > > > >
> > > > > > On Thu, Nov 10, 2016 at 10:23 AM, radai <
> radai.rosenblatt@gmail.com>
> > > > > > wrote:
> > > > > > > with java 7 being EOL'ed for more than a year and a half now
> (apr
> > > > 2015,
> > > > > > see
> > > > > > > http://www.oracle.com/technetwork/java/eol-135779.html) i was
> > > > > wondering
> > > > > > if
> > > > > > > there's an official plan/timetable for transitioning the kafka
> > > > codebase
> > > > > > > over to java 8?
> > > > > >
> > > > >
> > > >
> > >
>