+1 On Tue, 21 Jun 2016 at 09:59 Marcus Gründler <marcus.gruend...@aixigo.de> wrote:
> 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 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 > >> > >> > > -- > > 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 > >
