Re: JDK 11 support.
Hello, That's a generic statement. Ignite uses the flags to enable Unsafe API support for its off-heap memory. So, it's safe to pass the flags for Ignite nodes processes. This will be optional once Unsafe is replaced with an alternate solution, presently there is no easy one. Once we come up with the solution and confirm it's as fast and robust as the current implementation then it will be taken to work. - Denis On Wed, Mar 13, 2019 at 9:43 AM Loredana Radulescu Ivanoff < lradu...@tibco.com> wrote: > Hello, > > I am very interested in this topic as well so I've been following up. So, > if I understand correctly, there is no other way to access the needed API's > without these flags, and the following (extract from Java documentation) is > an accepted risk? > > "*The --add-exports and --add-opens options must be used with great care. > You can use them to gain access to an internal API of a library module, or > even of the JDK itself, but you do so at your own risk: If that internal > API is changed or removed then your library or application will fail."* > > The quote is from the Breaking Encapsulation section in the link below: > https://openjdk.java.net/jeps/261 > > > > On Tue, Mar 12, 2019 at 2:15 PM Dmitriy Pavlov wrote: > >> Hi Shane, >> >> These flags are required to access JVM internals and are used by Ignite. >> And it is not related to production readiness. >> >> A number of projects require these flags. In theory in some future >> release Ignite can get rid of the mandatory specification of extra flags, >> but it will anyway affect performance. So in this scenario (if community >> accept it), Ignite will recommend to set it up but will be (much) slower >> without it. >> >> There are a number of open discussions at dev@ related to Java 11, >> modularity support. So AFAIK there are no exact plans. >> >> Sincerely, >> Dmitriy Pavlov >> >> вт, 12 мар. 2019 г. в 20:48, Shane Duan : >> >>> Currently running Ignite 2.7 with OpenJDK11, with these additional JVM >>> flags: >>> >>> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED >>> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED >>> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED >>> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED--illegal-access=permit-Djdk.tls.client.protocols=TLSv1.2 >>> >>> >>> It is working, but also brought some concerns whether Ignite is >>> production-ready... >>> >>> Any plan to remove these dependency on these flags in next release? >>> >>> Thanks! >>> >>> -Shane >>> >>> >>> >>> >>>
Re: JDK 11 support.
Hello! Ignite is very complex application which indeed have to be adjusted for every new major JDK release. So yes, basically it fails for every new JDK release when APIs change. Fortunately, you can control version of your JDK. Regards, -- Ilya Kasnacheev ср, 13 мар. 2019 г. в 19:43, Loredana Radulescu Ivanoff : > Hello, > > I am very interested in this topic as well so I've been following up. So, > if I understand correctly, there is no other way to access the needed API's > without these flags, and the following (extract from Java documentation) is > an accepted risk? > > "*The --add-exports and --add-opens options must be used with great care. > You can use them to gain access to an internal API of a library module, or > even of the JDK itself, but you do so at your own risk: If that internal > API is changed or removed then your library or application will fail."* > > The quote is from the Breaking Encapsulation section in the link below: > https://openjdk.java.net/jeps/261 > > > > On Tue, Mar 12, 2019 at 2:15 PM Dmitriy Pavlov wrote: > >> Hi Shane, >> >> These flags are required to access JVM internals and are used by Ignite. >> And it is not related to production readiness. >> >> A number of projects require these flags. In theory in some future >> release Ignite can get rid of the mandatory specification of extra flags, >> but it will anyway affect performance. So in this scenario (if community >> accept it), Ignite will recommend to set it up but will be (much) slower >> without it. >> >> There are a number of open discussions at dev@ related to Java 11, >> modularity support. So AFAIK there are no exact plans. >> >> Sincerely, >> Dmitriy Pavlov >> >> вт, 12 мар. 2019 г. в 20:48, Shane Duan : >> >>> Currently running Ignite 2.7 with OpenJDK11, with these additional JVM >>> flags: >>> >>> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED >>> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED >>> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED >>> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED--illegal-access=permit-Djdk.tls.client.protocols=TLSv1.2 >>> >>> >>> It is working, but also brought some concerns whether Ignite is >>> production-ready... >>> >>> Any plan to remove these dependency on these flags in next release? >>> >>> Thanks! >>> >>> -Shane >>> >>> >>> >>> >>>
Re: JDK 11 support.
Hello, I am very interested in this topic as well so I've been following up. So, if I understand correctly, there is no other way to access the needed API's without these flags, and the following (extract from Java documentation) is an accepted risk? "*The --add-exports and --add-opens options must be used with great care. You can use them to gain access to an internal API of a library module, or even of the JDK itself, but you do so at your own risk: If that internal API is changed or removed then your library or application will fail."* The quote is from the Breaking Encapsulation section in the link below: https://openjdk.java.net/jeps/261 On Tue, Mar 12, 2019 at 2:15 PM Dmitriy Pavlov wrote: > Hi Shane, > > These flags are required to access JVM internals and are used by Ignite. > And it is not related to production readiness. > > A number of projects require these flags. In theory in some future release > Ignite can get rid of the mandatory specification of extra flags, but it > will anyway affect performance. So in this scenario (if community accept > it), Ignite will recommend to set it up but will be (much) slower without > it. > > There are a number of open discussions at dev@ related to Java 11, > modularity support. So AFAIK there are no exact plans. > > Sincerely, > Dmitriy Pavlov > > вт, 12 мар. 2019 г. в 20:48, Shane Duan : > >> Currently running Ignite 2.7 with OpenJDK11, with these additional JVM >> flags: >> >> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED >> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED >> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED >> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED--illegal-access=permit-Djdk.tls.client.protocols=TLSv1.2 >> >> >> It is working, but also brought some concerns whether Ignite is >> production-ready... >> >> Any plan to remove these dependency on these flags in next release? >> >> Thanks! >> >> -Shane >> >> >> >> >>
Re: JDK 11 support.
Very much appreciated, Dmitriy! On Tue, Mar 12, 2019 at 2:15 PM Dmitriy Pavlov wrote: > Hi Shane, > > These flags are required to access JVM internals and are used by Ignite. > And it is not related to production readiness. > > A number of projects require these flags. In theory in some future release > Ignite can get rid of the mandatory specification of extra flags, but it > will anyway affect performance. So in this scenario (if community accept > it), Ignite will recommend to set it up but will be (much) slower without > it. > > There are a number of open discussions at dev@ related to Java 11, > modularity support. So AFAIK there are no exact plans. > > Sincerely, > Dmitriy Pavlov > > вт, 12 мар. 2019 г. в 20:48, Shane Duan : > >> Currently running Ignite 2.7 with OpenJDK11, with these additional JVM >> flags: >> >> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED >> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED >> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED >> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED--illegal-access=permit-Djdk.tls.client.protocols=TLSv1.2 >> >> >> It is working, but also brought some concerns whether Ignite is >> production-ready... >> >> Any plan to remove these dependency on these flags in next release? >> >> Thanks! >> >> -Shane >> >> >> >> >>
Re: JDK 11 support.
Hi Shane, These flags are required to access JVM internals and are used by Ignite. And it is not related to production readiness. A number of projects require these flags. In theory in some future release Ignite can get rid of the mandatory specification of extra flags, but it will anyway affect performance. So in this scenario (if community accept it), Ignite will recommend to set it up but will be (much) slower without it. There are a number of open discussions at dev@ related to Java 11, modularity support. So AFAIK there are no exact plans. Sincerely, Dmitriy Pavlov вт, 12 мар. 2019 г. в 20:48, Shane Duan : > Currently running Ignite 2.7 with OpenJDK11, with these additional JVM > flags: > > --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED > --add-exports=java.base/sun.nio.ch=ALL-UNNAMED > --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED > --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED--illegal-access=permit-Djdk.tls.client.protocols=TLSv1.2 > > > It is working, but also brought some concerns whether Ignite is > production-ready... > > Any plan to remove these dependency on these flags in next release? > > Thanks! > > -Shane > > > > >
JDK 11 support.
Currently running Ignite 2.7 with OpenJDK11, with these additional JVM flags: --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED--illegal-access=permit-Djdk.tls.client.protocols=TLSv1.2 It is working, but also brought some concerns whether Ignite is production-ready... Any plan to remove these dependency on these flags in next release? Thanks! -Shane
Re: JDK 11 support
Currently, compilation is not supported, efforts are about providing runtime compatibility. I hope full support (compilation + runtime) will be introduced in 2.8 (and not later than 3.0). > On 9 Jan 2019, at 11:27, zaleslaw wrote: > > I haven't any troubles with running Ignite 2.6 with JDK 8 and Ignite 2.7 with > JDK 8,9. > But a few weeks ago it [Ignite 2.6/Ignite 2.7) doesn't compile with JDK 11 > (Oracle). > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDK 11 support
I haven't any troubles with running Ignite 2.6 with JDK 8 and Ignite 2.7 with JDK 8,9. But a few weeks ago it [Ignite 2.6/Ignite 2.7) doesn't compile with JDK 11 (Oracle). -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDK 11 support
I can run it in 2.6 by adding these to the JVM arguments: --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-exports=java.base/sun.nio.ch=ALL-UNNAMED I haven't had a chance to try with 2.7 yet, I would have expected it to work without these, though. Is this going to be addressed in 2.8, maybe? On Mon, Jan 7, 2019 at 6:44 AM ignite_user2016 wrote: > I am running Ignite 2.7 on JDK 11 but getting following error - > > c:\apache-ignite-2.7.0-bin\bin>ignite.bat > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.ignite.internal.util.GridUnsafe$2 > (file:/C:/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar) to field > java.nio.Buffer.address > WARNING: Please consider reporting this to the maintainers of > org.apache.ignite.internal.util.GridUnsafe$2 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > Exception in thread "main" java.lang.ExceptionInInitializerError > at > org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795) > at > > org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305) > at > > org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71) > at > > org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99) > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess > class > is unavailable. > at > > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453) > at > org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112) > ... 4 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @689604d9 > at > > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) > at > > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) > at java.base/java.lang.reflect.Method.invoke(Method.java:558) > at > > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450) > ... 5 more > Press any key to continue . . . > > c:\apache-ignite-2.7.0-bin\bin>java -version > java version "11.0.1" 2018-10-16 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode) > > c:\apache-ignite-2.7.0-bin\bin>control.bat > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: JDK 11 support
I am running Ignite 2.7 on JDK 11 but getting following error - c:\apache-ignite-2.7.0-bin\bin>ignite.bat WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.ignite.internal.util.GridUnsafe$2 (file:/C:/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar) to field java.nio.Buffer.address WARNING: Please consider reporting this to the maintainers of org.apache.ignite.internal.util.GridUnsafe$2 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Exception in thread "main" java.lang.ExceptionInInitializerError at org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795) at org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305) at org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71) at org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99) Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class is unavailable. at org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453) at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112) ... 4 more Caused by: java.lang.IllegalAccessException: class org.apache.ignite.internal.util.GridUnsafe cannot access class jdk.internal.misc.SharedSecrets (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @689604d9 at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) at java.base/java.lang.reflect.Method.invoke(Method.java:558) at org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450) ... 5 more Press any key to continue . . . c:\apache-ignite-2.7.0-bin\bin>java -version java version "11.0.1" 2018-10-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode) c:\apache-ignite-2.7.0-bin\bin>control.bat -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDK 11 support
Of course jdk 8 is fine :). I meant that ignite should also be fine with jdk9 and newer. Yakov
Re: JDK 11 support
No. I have run it on jdk 8 also On Sunday, January 6, 2019, Yakov Zhdanov wrote: > Ignite 2.7 should run on JDK 11. Vladimir, Denis, correct me if I'm wrong. > > Please try this link for information - https://apacheignite.readme. > io/v2.7/docs/getting-started#section-running-ignite-with-java-9 > > --Yakov >
Re: JDK 11 support
Ignite 2.7 should run on JDK 11. Vladimir, Denis, correct me if I'm wrong. Please try this link for information - https://apacheignite.readme.io/v2.7/docs/getting-started#section-running-ignite-with-java-9 --Yakov
Re: JDK 11 support
i think you must run ignite on JDK 8. On Sat, Jan 5, 2019 at 7:03 PM ignite_user2016 wrote: > what version of Ignite run on JDK 11 ? Does any one tried running Ignite on > open JDK 11 ? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: JDK 11 support
what version of Ignite run on JDK 11 ? Does any one tried running Ignite on open JDK 11 ? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDK 11 support
Ok. Thx for quick answer. January 2019 sounds good. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDK 11 support
For now seems that JDK 11 is not available yet (EAP is not an option). I think the best hope of full JDK11 support is JDK8 maintenance drop date (around Jan 2019). > On 10 Sep 2018, at 16:17, ipsxd wrote: > > For now seems that Ignite cannot start with JDK 11, I assume there is a plan > to migrate to 11 and if can you specify what the timeline ? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
JDK 11 support
For now seems that Ignite cannot start with JDK 11, I assume there is a plan to migrate to 11 and if can you specify what the timeline ? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
