Hi Joe, Thanks for your feedback.
Compatibility is a complex subject and the exact details need to be defined for each project. Technically, one could claim that making changes so that a 0.10.1.0 client doesn't work with a 0.10.0.0 broker would be an incompatible change and should not be allowed, but we don't have such a rule for Kafka today. Bumping the minimum required Java version could be seen as an incompatible change that needs a major release or not since users don't have to change or recompile their code (as I mentioned elsewhere, Akka 2.4.0 is fully compatible apart from the bump in the JDK version). For what is worth, the Java 6 to Java 7 transition in Kafka (KAFKA-2316) was proposed in July of last year by Harsha in the middle of the 0.8.3 cycle and it was approved. The rename of 0.8.3 to 0.9.0 was only raised in September by Gwen and the reasons given were: "What do you think of making the next release (the one with security, new consumer, quotas, etc) a 0.9.0 instead of 0.8.3? It has lots of new features, and new consumer was pretty much scoped for 0.9.0, so it matches our original roadmap. I feel that so many awesome features deserve a better release number." No Java bump mentioned there or elsewhere I could see. So, it seems like this is a new rule we are trying to introduce. Which is not necessarily an issue, but it's important to make it clear. Ismael On Fri, Jun 17, 2016 at 3:38 PM, Joe Stein <joe.st...@stealth.ly> wrote: > Compatibility shouldn't be broken in a minor release. Minor versions are > for new features in a backwards-compatible manner. The Kafka bylaws do not > explicitly state this but I believe it is implied based on general practice > and so many other Apache projects explicitly calling this out, documenting > and communicating their semantic version strategy. > > If JDK8 is so much desired then jump to 0.11 and only do bug fixes on the > 0.10 release (which should be rigorous and not forceful to make folks > upgrade unnecessarily to get such improvements). > > My 0.2824152382 cents. > > Regards, > > ~ Joe Stein > > On Fri, Jun 17, 2016 at 8:53 AM, Marina <ppi...@yahoo.com.invalid> wrote: > > > +1 - wish it was already done with Kafka 0.9 version :) > > > > > > From: Tommy Becker <tobec...@tivo.com> > > To: users@kafka.apache.org > > Sent: Friday, June 17, 2016 7:55 AM > > Subject: Re: [DISCUSS] Java 8 as a minimum requirement > > > > +1 We're on Java 8 already. > > > > On 06/16/2016 04:45 PM, Ismael Juma wrote: > > > > Hi all, > > > > I would like to start a discussion on making Java 8 a minimum requirement > > for Kafka's next feature release (let's say Kafka 0.10.1.0 for now). This > > is the first discussion on the topic so the idea is to understand how > > people feel about it. If people feel it's too soon, then we can pick up > the > > conversation again after Kafka 0.10.1.0. If the feedback is mostly > > positive, I will start a vote thread. > > > > Let's start with some dates. Java 7 hasn't received public updates since > > April 2015[1], Java 8 was released in March 2014[2] and Java 9 is > scheduled > > to be released in March 2017[3]. > > > > The first argument for dropping support for Java 7 is that the last > public > > release by Oracle contains a large number of known security > > vulnerabilities. The effectiveness of Kafka's security features is > reduced > > if the underlying runtime is not itself secure. > > > > The second argument for moving to Java 8 is that it adds a number of > > compelling features: > > > > * Lambda expressions and method references (particularly useful for the > > Kafka Streams DSL) > > * Default methods (very useful for maintaining compatibility when adding > > methods to interfaces) > > * java.util.stream (helpful for making collection transformations more > > concise) > > * Lots of improvements to java.util.concurrent (CompletableFuture, > > DoubleAdder, DoubleAccumulator, StampedLock, LongAdder, LongAccumulator) > > * Other nice things: SplittableRandom, Optional (and many others I have > not > > mentioned) > > > > The third argument is that it will simplify our testing matrix, we won't > > have to test with Java 7 any longer (this is particularly useful for > system > > tests that take hours to run). It will also make it easier to support > Scala > > 2.12, which requires Java 8. > > > > The fourth argument is that many other open-source projects have taken > the > > leap already. 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). This reduces (but does not > > eliminate) the chance that we would be the first project that would > cause a > > user to consider a Java upgrade. > > > > The main argument for not making the change is that a reasonable number > of > > users may still be using Java 7 by the time Kafka 0.10.1.0 is released. > > More specifically, we care about the subset who would be able to upgrade > to > > Kafka 0.10.1.0, but would not be able to upgrade the Java version. It > would > > be great if we could quantify this in some way. > > > > What do you think? > > > > Ismael > > > > [1] https://java.com/en/download/faq/java_7.xml > > [2] https://blogs.oracle.com/thejavatutorials/entry/jdk_8_is_released > > [3] http://openjdk.java.net/projects/jdk9/ > > [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 > > > > > > > > -- > > Tommy Becker > > Senior Software Engineer > > > > Digitalsmiths > > A TiVo Company > > > > www.digitalsmiths.com<http://www.digitalsmiths.com> > > tobec...@tivo.com<mailto:tobec...@tivo.com> > > > > ________________________________ > > > > This email and any attachments may contain confidential and privileged > > material for the sole use of the intended recipient. Any review, copying, > > or distribution of this email (or any attachments) by others is > prohibited. > > If you are not the intended recipient, please contact the sender > > immediately and permanently delete this email and any attachments. No > > employee or agent of TiVo Inc. is authorized to conclude any binding > > agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo > > Inc. may only be made by a signed written agreement. > > > > > > >
