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 <radai.rosenbl...@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 <ism...@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 <jjkosh...@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.mccaul...@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.rosenbl...@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? > > > > > > > > > >
