any plans to switch to java 8?

[radai <ra...@gmail.com>]

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?

[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?
> > > > > >
> > > > >
> > > >
> > >
>

Re: any plans to switch to java 8?

[Colin McCabe <cm...@apache.org>]

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?

[Ismael Juma <is...@juma.me.uk>]

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?

[radai <ra...@gmail.com>]

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?

[Ismael Juma <is...@juma.me.uk>]

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?

[Joel Koshy <jj...@gmail.com>]

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 <se...@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?

[Sean McCauliff <se...@gmail.com>]

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?