Hi Vladimir, Do you know if update notifier can get and record java version from a node and send it to Apache Ignite site? Or/And what is the most popular version now?
I guess most existing users will continue to use their current Java, most likely Java 8. And they will also require a huge amount of time to migrate. Sincerely, Dmitriy Pavlov чт, 20 сент. 2018 г. в 23:00, Vladimir Ozerov <voze...@gridgain.com>: > Igniters, we have a problem. > > *TL;DR;* > Ignite may be seriously broken in Java 11. This affects ignite.sh, > Hibernate integration, JTA integration. And we cannot test it before code > freeze due to Java 11 release schedule. > > We need to understand whether we shift release, or plan immediate AI 2.8 > afterwarвs, or ignore the problem until a number of user compliants appear. > > *Long story* > As you may know we already put some efforts on Java 9 support in Ignite > [1]. Specifically, during earlier releases we reworked all code affected by > Java 9 changes and added several "--add-export" and "--add-module" flags to > support some packages which are not accessible by default. We never > implemented any modules in Ignite. > > As a result, currently Apache Ignite mostly works fine with Java 9. If node > is started in standalone mode, we add mentioned flags to JVM arguments by > default, and no actions are needed from user side. If node is started in > embedded mode, user has to provide required flags manually [2]. This is > acceptable state for us until module subsystem is integrated somehow with > the product. > > But then we decided to perform extensive testing of current master on Java > 9/10/11 versions. Thanks to Peter Ivanov, we setup required environment. > During this activity we read more docs about Java 11. We revealed, that in > this release a number of packages we depend on will be removed completely > from JDK as a part of JEP 320 [3]. *JTA *and *Hibernate* integrations will > stop work out of the box. Moreover, "--add-module" flag will stop working, > what may affect ignite.sh. > > Things are even worse because Java 11 will be released exactly by our > planned code freeze date, so we cannot even test it appropriately right > now. So we need to revisit out Java 9+ support strategy for the nearest > releases. > > *Possible solutions* > 1) Relax and move Java 9+ support to AI 2.8 scope > Pros: Java 8 will be supported till January 2019 [4] so we still have some > time. We can plan AI 2.8 to Nov-Dec this year. > Cons: more and more users will try Java 11 (not Java 9 or 10, they will be > hidden from official page) during this time, and without Java 11 testing we > may end up with not-working product. > > 2) Move AI 2.7 code freeze to the middle of October to have a time to test > and fix big problems with Java 11. > Pros: Java 11 will be released in the end of the next week [5]. We take > some additional time to test us with Java 11, fix what can be fixed, find > and document workaround for things which cannot be fixed. > Cons: AI 2.7 will be released in the end of October. > > Another small "cons" for the second approach is that we will have more time > for MVCC stabilization, and improve chances of service grid to be included > into release (from what I heard from Nikolay and Vyacheslav, there is a > good progress for now). But remember that our previous expirience with > things like that is constantly shifting release dates. > > Please share your thoughts on what should we do with Java 11. > > Vladimir. > > [1] https://issues.apache.org/jira/browse/IGNITE-6728 > [2] https://issues.apache.org/jira/browse/IGNITE-9288 > [3] http://openjdk.java.net/jeps/320 > [4] https://www.oracle.com/technetwork/java/javase/eol-135779.html > [5] http://www.java-countdown.xyz/ >
