Re: [DISCUSS] Java 8 as a minimum requirement

[Marcus Gründler]

Hi Ismael,

thanks for the pointer to the latest WebSphere documentation - I wasn’t aware 
of that release.

We currently have customers that run our software frontend on an older 
WebSphere version that runs on Java 7 and push data to kafka brokers in the 
backend. Replacing Kafka brokers wouldn’t be an issue here since we are in 
control of the backend part.

The WebSphere server where our frontend part (and therefore our kafka client) 
is running is a kind of general infrastructure of that customer and upgrade 
cycles are slow and independent of our release cycles.

Of course that could be solved by a kind of proxy in front of the kafka 
brokers, 
so maybe we shouldn’t pay too much tribute to legacy systems :-)

Regards, Marcus


> Am 17.06.2016 um 15:44 schrieb Ismael Juma <ism...@juma.me.uk>:
> 
> Hi Marcus,
> 
> Thanks for your feedback.
> 
> With regards to IBM WebSphere, the latest stable release (8.5.5) supports
> Java 8 according to the documentation:
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg27005002
> 
> Having said that, it is fair to discuss servers and clients separately. In
> Kafka, you can't use newer clients with older brokers, but you can use
> older clients with newer brokers. As such, the scenario we're talking about
> is that of users who can upgrade their brokers and clients to the latest
> Kafka version, but are stuck with an older version of WebSphere, right? Are
> you aware of such users?
> 
> Ismael
> On Fri, Jun 17, 2016 at 10:34 AM, Marcus Gründler <
> marcus.gruend...@aixigo.de> wrote:
> 
>> -1
>> Hi Ismael,
>> 
>> Although I really like the Java 8 features and understand the advantages
>> you
>> mentioned about Java 8 migration, I would suggest to stay with Java 7 as
>> a minimum requirement for a while.
>> 
>> I think there are two aspects to consider - Kafka Server and Kafka
>> clients. On
>> the server part it would make sense to switch to Java 8 because you can run
>> the broker independently from any enclosing runtime (no JEE server etc.)
>> 
>> But if you change the requirement for Kafka clients, you would cut Kafka
>> support for quite a lot of real world deployments that run for example on
>> an IBM WebSphere JEE Server (*sigh*). Since up to today there is no
>> WebSphere version that supports Java 8.
>> 
>> And I think a split of Kafka server with Java8 and Kafka client JARs in
>> Java7
>> would be too complicated to maintain.
>> 
>> So my conclusion is - stay with Java 7 for a while.
>> 
>> Regards, Marcus
>> 
>> 
>>> Am 16.06.2016 um 22:45 schrieb Ismael Juma <ism...@juma.me.uk>:
>>> 
>>> 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

Re: [DISCUSS] Java 8 as a minimum requirement

[Marcus Gründler]

-1
Hi Ismael,

Although I really like the Java 8 features and understand the advantages you
mentioned about Java 8 migration, I would suggest to stay with Java 7 as
a minimum requirement for a while.

I think there are two aspects to consider - Kafka Server and Kafka clients. On 
the server part it would make sense to switch to Java 8 because you can run
the broker independently from any enclosing runtime (no JEE server etc.)

But if you change the requirement for Kafka clients, you would cut Kafka
support for quite a lot of real world deployments that run for example on
an IBM WebSphere JEE Server (*sigh*). Since up to today there is no 
WebSphere version that supports Java 8.

And I think a split of Kafka server with Java8 and Kafka client JARs in Java7 
would be too complicated to maintain.

So my conclusion is - stay with Java 7 for a while.

Regards, Marcus


> Am 16.06.2016 um 22:45 schrieb Ismael Juma :
> 
> 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

-- 

aixigo AG - einfach. besser. beraten
Karl-Friedrich-Straße 68, 52072 Aachen, Germany
fon: +49 (0)241 559709-43, fax: +49 (0)241 559709-99
eMail: marcus.gruend...@aixigo.de, web: http://www.aixigo.de

Amtsgericht Aachen - HRB 8057
Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein
Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch