You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Shane Duan <sd...@gmail.com> on 2019/03/12 17:38:54 UTC
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.
Posted by Shane Duan <sd...@gmail.com>.
Very much appreciated, Dmitriy!
On Tue, Mar 12, 2019 at 2:15 PM Dmitriy Pavlov <dp...@apache.org> 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 <sd...@gmail.com>:
>
>> 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.
Posted by Denis Magda <dm...@apache.org>.
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 <
lradules@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 <dp...@apache.org> 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 <sd...@gmail.com>:
>>
>>> 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.
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <lradules@tibco.com
>:
> 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 <dp...@apache.org> 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 <sd...@gmail.com>:
>>
>>> 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.
Posted by Loredana Radulescu Ivanoff <lr...@tibco.com>.
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 <dp...@apache.org> 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 <sd...@gmail.com>:
>
>> 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.
Posted by Dmitriy Pavlov <dp...@apache.org>.
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 <sd...@gmail.com>:
> 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
>
>
>
>
>