In general, I'm totally for the plan 2 - make sure Ignite works with Java 11 and release it in October. However, are we sure we'll be ready to adopt JTA and Hibernate integrations? We can't release having them broken.
-- Denis On Thu, Sep 20, 2018 at 4:00 PM Vladimir Ozerov <voze...@gridgain.com> wrote: > 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/ >
