Hi Ignite Developers,
During the start of Ignite node under Java 11 (actually 9+) or during local development you may face with warning related to illegal access. You know that Ignite uses Unsafe operation for durable memory. Accessing to Unsafe requires --illegal-access=permit (Now it is the default for JVM. From the doc: permit: ... The first reflective-access operation to any such package causes a warning to be issued. However, no warnings are issued after the first occurrence. This single warning describes how to enable further warnings. Warning example: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.ignite.internal.util.GridUnsafe$2 (file:..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 Unfortunately removing or disabling this warning is absolutely impossible, it is generated by JVM and there is no option to disable it: https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE Sincerely, Dmitriy Pavlov |
Hello!
I wonder if we could try to redirect output to null, initialize GridUnsafe and then bring output back :) Regards, -- Ilya Kasnacheev ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > Hi Ignite Developers, > > During the start of Ignite node under Java 11 (actually 9+) or during local > development you may face with warning related to illegal access. > > You know that Ignite uses Unsafe operation for durable memory. > > Accessing to Unsafe requires --illegal-access=permit (Now it is the default > for JVM. From the doc: > permit: ... The first reflective-access operation to any such package > causes a warning to be issued. However, no warnings are issued after the > first occurrence. This single warning describes how to enable further > warnings. > > Warning example: > > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.ignite.internal.util.GridUnsafe$2 > (file:..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 > > > Unfortunately removing or disabling this warning is absolutely impossible, > it is generated by JVM and there is no option to disable it: > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > Sincerely, > Dmitriy Pavlov > |
Sure, we could try this option.
ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev <[hidden email]>: > Hello! > > I wonder if we could try to redirect output to null, initialize GridUnsafe > and then bring output back :) > > Regards, > -- > Ilya Kasnacheev > > > ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > > > Hi Ignite Developers, > > > > During the start of Ignite node under Java 11 (actually 9+) or during > local > > development you may face with warning related to illegal access. > > > > You know that Ignite uses Unsafe operation for durable memory. > > > > Accessing to Unsafe requires --illegal-access=permit (Now it is the > default > > for JVM. From the doc: > > permit: ... The first reflective-access operation to any such package > > causes a warning to be issued. However, no warnings are issued after the > > first occurrence. This single warning describes how to enable further > > warnings. > > > > Warning example: > > > > WARNING: An illegal reflective access operation has occurred > > WARNING: Illegal reflective access by > > org.apache.ignite.internal.util.GridUnsafe$2 > > (file:..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 > > > > > > Unfortunately removing or disabling this warning is absolutely > impossible, > > it is generated by JVM and there is no option to disable it: > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > Sincerely, > > Dmitriy Pavlov > > > |
It's fine as long as the project can be launched. I would better start
looking for Unsafe alternatives as the next step. We can't live with it forever, the time to phase it out has come :) - Denis On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> wrote: > Sure, we could try this option. > > ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev <[hidden email]>: > > > Hello! > > > > I wonder if we could try to redirect output to null, initialize > GridUnsafe > > and then bring output back :) > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > > > > > Hi Ignite Developers, > > > > > > During the start of Ignite node under Java 11 (actually 9+) or during > > local > > > development you may face with warning related to illegal access. > > > > > > You know that Ignite uses Unsafe operation for durable memory. > > > > > > Accessing to Unsafe requires --illegal-access=permit (Now it is the > > default > > > for JVM. From the doc: > > > permit: ... The first reflective-access operation to any such package > > > causes a warning to be issued. However, no warnings are issued after > the > > > first occurrence. This single warning describes how to enable further > > > warnings. > > > > > > Warning example: > > > > > > WARNING: An illegal reflective access operation has occurred > > > WARNING: Illegal reflective access by > > > org.apache.ignite.internal.util.GridUnsafe$2 > > > (file:..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 > > > > > > > > > Unfortunately removing or disabling this warning is absolutely > > impossible, > > > it is generated by JVM and there is no option to disable it: > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > |
According to warning message, there are no options at all, as Unsafe may become unavailable in any time.
> On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > It's fine as long as the project can be launched. I would better start > looking for Unsafe alternatives as the next step. We can't live with it > forever, the time to phase it out has come :) > > - > Denis > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> wrote: > >> Sure, we could try this option. >> >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev <[hidden email]>: >> >>> Hello! >>> >>> I wonder if we could try to redirect output to null, initialize >> GridUnsafe >>> and then bring output back :) >>> >>> Regards, >>> -- >>> Ilya Kasnacheev >>> >>> >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: >>> >>>> Hi Ignite Developers, >>>> >>>> During the start of Ignite node under Java 11 (actually 9+) or during >>> local >>>> development you may face with warning related to illegal access. >>>> >>>> You know that Ignite uses Unsafe operation for durable memory. >>>> >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the >>> default >>>> for JVM. From the doc: >>>> permit: ... The first reflective-access operation to any such package >>>> causes a warning to be issued. However, no warnings are issued after >> the >>>> first occurrence. This single warning describes how to enable further >>>> warnings. >>>> >>>> Warning example: >>>> >>>> WARNING: An illegal reflective access operation has occurred >>>> WARNING: Illegal reflective access by >>>> org.apache.ignite.internal.util.GridUnsafe$2 >>>> (file:..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 >>>> >>>> >>>> Unfortunately removing or disabling this warning is absolutely >>> impossible, >>>> it is generated by JVM and there is no option to disable it: >>>> >>>> >>> >> https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE >>>> >>>> >>>> Sincerely, >>>> Dmitriy Pavlov >>>> >>> >> |
Also it worth to consider a case when Ignite is used as a library. In
that case it is not correct to disable these warnings because there could be warnings for other libraries too. On the other hand we might employ some tricks in CommandLineStartup when running alone. чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > According to warning message, there are no options at all, as Unsafe may become unavailable in any time. > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > It's fine as long as the project can be launched. I would better start > > looking for Unsafe alternatives as the next step. We can't live with it > > forever, the time to phase it out has come :) > > > > - > > Denis > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> wrote: > > > >> Sure, we could try this option. > >> > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev <[hidden email]>: > >> > >>> Hello! > >>> > >>> I wonder if we could try to redirect output to null, initialize > >> GridUnsafe > >>> and then bring output back :) > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > >>> > >>>> Hi Ignite Developers, > >>>> > >>>> During the start of Ignite node under Java 11 (actually 9+) or during > >>> local > >>>> development you may face with warning related to illegal access. > >>>> > >>>> You know that Ignite uses Unsafe operation for durable memory. > >>>> > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the > >>> default > >>>> for JVM. From the doc: > >>>> permit: ... The first reflective-access operation to any such package > >>>> causes a warning to be issued. However, no warnings are issued after > >> the > >>>> first occurrence. This single warning describes how to enable further > >>>> warnings. > >>>> > >>>> Warning example: > >>>> > >>>> WARNING: An illegal reflective access operation has occurred > >>>> WARNING: Illegal reflective access by > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > >>>> (file:..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 > >>>> > >>>> > >>>> Unfortunately removing or disabling this warning is absolutely > >>> impossible, > >>>> it is generated by JVM and there is no option to disable it: > >>>> > >>>> > >>> > >> https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > >>>> > >>>> > >>>> Sincerely, > >>>> Dmitriy Pavlov > >>>> > >>> > >> > -- Best regards, Ivan Pavlukhin |
Guys,
The issue is that we chose the easiest way to start working with Java 9+, which is the illegal-access=permit. This is a blanket option that affects the whole VM which is better to avoid – hence the warnings. A better solution is to use --add-opens statements. Same as add-exports, one needs to specify an add-opens for every package that is going to be accessed via reflection with setAccessible(true). To find all of the packages we need to open, we could do a bunch of runs with Illegal-access=deny and add an add-opens option for each error we see. There will be a lot, I guess. Stan From: Павлухин Иван Sent: 28 февраля 2019 г. 9:36 To: [hidden email] Subject: Re: JVM warnings during Java 11 startup Also it worth to consider a case when Ignite is used as a library. In that case it is not correct to disable these warnings because there could be warnings for other libraries too. On the other hand we might employ some tricks in CommandLineStartup when running alone. чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > According to warning message, there are no options at all, as Unsafe may become unavailable in any time. > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > It's fine as long as the project can be launched. I would better start > > looking for Unsafe alternatives as the next step. We can't live with it > > forever, the time to phase it out has come :) > > > > - > > Denis > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> wrote: > > > >> Sure, we could try this option. > >> > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev <[hidden email]>: > >> > >>> Hello! > >>> > >>> I wonder if we could try to redirect output to null, initialize > >> GridUnsafe > >>> and then bring output back :) > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > >>> > >>>> Hi Ignite Developers, > >>>> > >>>> During the start of Ignite node under Java 11 (actually 9+) or during > >>> local > >>>> development you may face with warning related to illegal access. > >>>> > >>>> You know that Ignite uses Unsafe operation for durable memory. > >>>> > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the > >>> default > >>>> for JVM. From the doc: > >>>> permit: ... The first reflective-access operation to any such package > >>>> causes a warning to be issued. However, no warnings are issued after > >> the > >>>> first occurrence. This single warning describes how to enable further > >>>> warnings. > >>>> > >>>> Warning example: > >>>> > >>>> WARNING: An illegal reflective access operation has occurred > >>>> WARNING: Illegal reflective access by > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > >>>> (file:..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 > >>>> > >>>> > >>>> Unfortunately removing or disabling this warning is absolutely > >>> impossible, > >>>> it is generated by JVM and there is no option to disable it: > >>>> > >>>> > >>> > >> https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > >>>> > >>>> > >>>> Sincerely, > >>>> Dmitriy Pavlov > >>>> > >>> > >> > -- Best regards, Ivan Pavlukhin |
In reply to this post by vveider
> may become unavailable in any time.
I remember this was discussed in 2013 that Unsafe will be removed soon. But nothing is changed yet, so I hope unsafe will be available for a long time (with flags/hacks/etc). чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > According to warning message, there are no options at all, as Unsafe may > become unavailable in any time. > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > It's fine as long as the project can be launched. I would better start > > looking for Unsafe alternatives as the next step. We can't live with it > > forever, the time to phase it out has come :) > > > > - > > Denis > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> > wrote: > > > >> Sure, we could try this option. > >> > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > [hidden email]>: > >> > >>> Hello! > >>> > >>> I wonder if we could try to redirect output to null, initialize > >> GridUnsafe > >>> and then bring output back :) > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > >>> > >>>> Hi Ignite Developers, > >>>> > >>>> During the start of Ignite node under Java 11 (actually 9+) or during > >>> local > >>>> development you may face with warning related to illegal access. > >>>> > >>>> You know that Ignite uses Unsafe operation for durable memory. > >>>> > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the > >>> default > >>>> for JVM. From the doc: > >>>> permit: ... The first reflective-access operation to any such package > >>>> causes a warning to be issued. However, no warnings are issued after > >> the > >>>> first occurrence. This single warning describes how to enable further > >>>> warnings. > >>>> > >>>> Warning example: > >>>> > >>>> WARNING: An illegal reflective access operation has occurred > >>>> WARNING: Illegal reflective access by > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > >>>> (file:..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 > >>>> > >>>> > >>>> Unfortunately removing or disabling this warning is absolutely > >>> impossible, > >>>> it is generated by JVM and there is no option to disable it: > >>>> > >>>> > >>> > >> > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > >>>> > >>>> > >>>> Sincerely, > >>>> Dmitriy Pavlov > >>>> > >>> > >> > > |
In reply to this post by Ivan Pavlukhin
Ivan, thanks, great consideration.
And probably for this warning, Java will probably resist to redirecting it at Java level. Anyway, we could try it because we know where the first Unsafe call is performed in Ignite. чт, 28 февр. 2019 г. в 09:36, Павлухин Иван <[hidden email]>: > Also it worth to consider a case when Ignite is used as a library. In > that case it is not correct to disable these warnings because there > could be warnings for other libraries too. > > On the other hand we might employ some tricks in CommandLineStartup > when running alone. > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > > According to warning message, there are no options at all, as Unsafe may > become unavailable in any time. > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > > > It's fine as long as the project can be launched. I would better start > > > looking for Unsafe alternatives as the next step. We can't live with it > > > forever, the time to phase it out has come :) > > > > > > - > > > Denis > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> > wrote: > > > > > >> Sure, we could try this option. > > >> > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > [hidden email]>: > > >> > > >>> Hello! > > >>> > > >>> I wonder if we could try to redirect output to null, initialize > > >> GridUnsafe > > >>> and then bring output back :) > > >>> > > >>> Regards, > > >>> -- > > >>> Ilya Kasnacheev > > >>> > > >>> > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > > >>> > > >>>> Hi Ignite Developers, > > >>>> > > >>>> During the start of Ignite node under Java 11 (actually 9+) or > during > > >>> local > > >>>> development you may face with warning related to illegal access. > > >>>> > > >>>> You know that Ignite uses Unsafe operation for durable memory. > > >>>> > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the > > >>> default > > >>>> for JVM. From the doc: > > >>>> permit: ... The first reflective-access operation to any such > package > > >>>> causes a warning to be issued. However, no warnings are issued after > > >> the > > >>>> first occurrence. This single warning describes how to enable > further > > >>>> warnings. > > >>>> > > >>>> Warning example: > > >>>> > > >>>> WARNING: An illegal reflective access operation has occurred > > >>>> WARNING: Illegal reflective access by > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > >>>> (file:..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 > > >>>> > > >>>> > > >>>> Unfortunately removing or disabling this warning is absolutely > > >>> impossible, > > >>>> it is generated by JVM and there is no option to disable it: > > >>>> > > >>>> > > >>> > > >> > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > >>>> > > >>>> > > >>>> Sincerely, > > >>>> Dmitriy Pavlov > > >>>> > > >>> > > >> > > > > > -- > Best regards, > Ivan Pavlukhin > |
In reply to this post by Dmitry Pavlov
Flags/hacks is not a way to go for serious and mature projects like Ignite.
We should switch to another mode - how to replace Unsafe completely. - Denis On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov <[hidden email]> wrote: > > may become unavailable in any time. > > I remember this was discussed in 2013 that Unsafe will be removed soon. But > nothing is changed yet, so I hope unsafe will be available for a long time > (with flags/hacks/etc). > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > According to warning message, there are no options at all, as Unsafe may > > become unavailable in any time. > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > > > It's fine as long as the project can be launched. I would better start > > > looking for Unsafe alternatives as the next step. We can't live with it > > > forever, the time to phase it out has come :) > > > > > > - > > > Denis > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> > > wrote: > > > > > >> Sure, we could try this option. > > >> > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > [hidden email]>: > > >> > > >>> Hello! > > >>> > > >>> I wonder if we could try to redirect output to null, initialize > > >> GridUnsafe > > >>> and then bring output back :) > > >>> > > >>> Regards, > > >>> -- > > >>> Ilya Kasnacheev > > >>> > > >>> > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > > >>> > > >>>> Hi Ignite Developers, > > >>>> > > >>>> During the start of Ignite node under Java 11 (actually 9+) or > during > > >>> local > > >>>> development you may face with warning related to illegal access. > > >>>> > > >>>> You know that Ignite uses Unsafe operation for durable memory. > > >>>> > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the > > >>> default > > >>>> for JVM. From the doc: > > >>>> permit: ... The first reflective-access operation to any such > package > > >>>> causes a warning to be issued. However, no warnings are issued after > > >> the > > >>>> first occurrence. This single warning describes how to enable > further > > >>>> warnings. > > >>>> > > >>>> Warning example: > > >>>> > > >>>> WARNING: An illegal reflective access operation has occurred > > >>>> WARNING: Illegal reflective access by > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > >>>> (file:..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 > > >>>> > > >>>> > > >>>> Unfortunately removing or disabling this warning is absolutely > > >>> impossible, > > >>>> it is generated by JVM and there is no option to disable it: > > >>>> > > >>>> > > >>> > > >> > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > >>>> > > >>>> > > >>>> Sincerely, > > >>>> Dmitriy Pavlov > > >>>> > > >>> > > >> > > > > > |
Here is how our friends from Hazelcast tackle the problem [1]. Using
--add-opens as Stan proposed looks like a good option in short perspective. By the way to determine all illegally accessed packages we can use --illegal-access=warn, which does not deny operation but only prints a warning. I guess we can found the majority of packages by analyzing TC logs. WDYT? [1] https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > Flags/hacks is not a way to go for serious and mature projects like Ignite. > We should switch to another mode - how to replace Unsafe completely. > > - > Denis > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov <[hidden email]> wrote: > > > > may become unavailable in any time. > > > > I remember this was discussed in 2013 that Unsafe will be removed soon. But > > nothing is changed yet, so I hope unsafe will be available for a long time > > (with flags/hacks/etc). > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > > > According to warning message, there are no options at all, as Unsafe may > > > become unavailable in any time. > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > > > > > It's fine as long as the project can be launched. I would better start > > > > looking for Unsafe alternatives as the next step. We can't live with it > > > > forever, the time to phase it out has come :) > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> > > > wrote: > > > > > > > >> Sure, we could try this option. > > > >> > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > [hidden email]>: > > > >> > > > >>> Hello! > > > >>> > > > >>> I wonder if we could try to redirect output to null, initialize > > > >> GridUnsafe > > > >>> and then bring output back :) > > > >>> > > > >>> Regards, > > > >>> -- > > > >>> Ilya Kasnacheev > > > >>> > > > >>> > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > > > >>> > > > >>>> Hi Ignite Developers, > > > >>>> > > > >>>> During the start of Ignite node under Java 11 (actually 9+) or > > during > > > >>> local > > > >>>> development you may face with warning related to illegal access. > > > >>>> > > > >>>> You know that Ignite uses Unsafe operation for durable memory. > > > >>>> > > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the > > > >>> default > > > >>>> for JVM. From the doc: > > > >>>> permit: ... The first reflective-access operation to any such > > package > > > >>>> causes a warning to be issued. However, no warnings are issued after > > > >> the > > > >>>> first occurrence. This single warning describes how to enable > > further > > > >>>> warnings. > > > >>>> > > > >>>> Warning example: > > > >>>> > > > >>>> WARNING: An illegal reflective access operation has occurred > > > >>>> WARNING: Illegal reflective access by > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > >>>> (file:..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 > > > >>>> > > > >>>> > > > >>>> Unfortunately removing or disabling this warning is absolutely > > > >>> impossible, > > > >>>> it is generated by JVM and there is no option to disable it: > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > >>>> > > > >>>> > > > >>>> Sincerely, > > > >>>> Dmitriy Pavlov > > > >>>> > > > >>> > > > >> > > > > > > > > -- Best regards, Ivan Pavlukhin |
By the way. It is interesting that Unsafe class is not the source of
warnings. I checked (with java 10) that there is no warnings issued when Unsafe instance is accessed with good old reflective way. пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > Here is how our friends from Hazelcast tackle the problem [1]. Using > --add-opens as Stan proposed looks like a good option in short > perspective. By the way to determine all illegally accessed packages > we can use --illegal-access=warn, which does not deny operation but > only prints a warning. I guess we can found the majority of packages > by analyzing TC logs. > > WDYT? > > [1] https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > Flags/hacks is not a way to go for serious and mature projects like Ignite. > > We should switch to another mode - how to replace Unsafe completely. > > > > - > > Denis > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov <[hidden email]> wrote: > > > > > > may become unavailable in any time. > > > > > > I remember this was discussed in 2013 that Unsafe will be removed soon. But > > > nothing is changed yet, so I hope unsafe will be available for a long time > > > (with flags/hacks/etc). > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > > > > > According to warning message, there are no options at all, as Unsafe may > > > > become unavailable in any time. > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > > > > > > > It's fine as long as the project can be launched. I would better start > > > > > looking for Unsafe alternatives as the next step. We can't live with it > > > > > forever, the time to phase it out has come :) > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov <[hidden email]> > > > > wrote: > > > > > > > > > >> Sure, we could try this option. > > > > >> > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > [hidden email]>: > > > > >> > > > > >>> Hello! > > > > >>> > > > > >>> I wonder if we could try to redirect output to null, initialize > > > > >> GridUnsafe > > > > >>> and then bring output back :) > > > > >>> > > > > >>> Regards, > > > > >>> -- > > > > >>> Ilya Kasnacheev > > > > >>> > > > > >>> > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov <[hidden email]>: > > > > >>> > > > > >>>> Hi Ignite Developers, > > > > >>>> > > > > >>>> During the start of Ignite node under Java 11 (actually 9+) or > > > during > > > > >>> local > > > > >>>> development you may face with warning related to illegal access. > > > > >>>> > > > > >>>> You know that Ignite uses Unsafe operation for durable memory. > > > > >>>> > > > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it is the > > > > >>> default > > > > >>>> for JVM. From the doc: > > > > >>>> permit: ... The first reflective-access operation to any such > > > package > > > > >>>> causes a warning to be issued. However, no warnings are issued after > > > > >> the > > > > >>>> first occurrence. This single warning describes how to enable > > > further > > > > >>>> warnings. > > > > >>>> > > > > >>>> Warning example: > > > > >>>> > > > > >>>> WARNING: An illegal reflective access operation has occurred > > > > >>>> WARNING: Illegal reflective access by > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > >>>> (file:..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 > > > > >>>> > > > > >>>> > > > > >>>> Unfortunately removing or disabling this warning is absolutely > > > > >>> impossible, > > > > >>>> it is generated by JVM and there is no option to disable it: > > > > >>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > >>>> > > > > >>>> > > > > >>>> Sincerely, > > > > >>>> Dmitriy Pavlov > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin |
Would add opens require user to set up a longer line?
пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > By the way. It is interesting that Unsafe class is not the source of > warnings. I checked (with java 10) that there is no warnings issued > when Unsafe instance is accessed with good old reflective way. > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > > > Here is how our friends from Hazelcast tackle the problem [1]. Using > > --add-opens as Stan proposed looks like a good option in short > > perspective. By the way to determine all illegally accessed packages > > we can use --illegal-access=warn, which does not deny operation but > > only prints a warning. I guess we can found the majority of packages > > by analyzing TC logs. > > > > WDYT? > > > > [1] > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > > > Flags/hacks is not a way to go for serious and mature projects like > Ignite. > > > We should switch to another mode - how to replace Unsafe completely. > > > > > > - > > > Denis > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov <[hidden email]> > wrote: > > > > > > > > may become unavailable in any time. > > > > > > > > I remember this was discussed in 2013 that Unsafe will be removed > soon. But > > > > nothing is changed yet, so I hope unsafe will be available for a > long time > > > > (with flags/hacks/etc). > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > > > > > > > According to warning message, there are no options at all, as > Unsafe may > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > > > > > > > > > It's fine as long as the project can be launched. I would better > start > > > > > > looking for Unsafe alternatives as the next step. We can't live > with it > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > [hidden email]> > > > > > wrote: > > > > > > > > > > > >> Sure, we could try this option. > > > > > >> > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > [hidden email]>: > > > > > >> > > > > > >>> Hello! > > > > > >>> > > > > > >>> I wonder if we could try to redirect output to null, initialize > > > > > >> GridUnsafe > > > > > >>> and then bring output back :) > > > > > >>> > > > > > >>> Regards, > > > > > >>> -- > > > > > >>> Ilya Kasnacheev > > > > > >>> > > > > > >>> > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > [hidden email]>: > > > > > >>> > > > > > >>>> Hi Ignite Developers, > > > > > >>>> > > > > > >>>> During the start of Ignite node under Java 11 (actually 9+) or > > > > during > > > > > >>> local > > > > > >>>> development you may face with warning related to illegal > access. > > > > > >>>> > > > > > >>>> You know that Ignite uses Unsafe operation for durable memory. > > > > > >>>> > > > > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it > is the > > > > > >>> default > > > > > >>>> for JVM. From the doc: > > > > > >>>> permit: ... The first reflective-access operation to any such > > > > package > > > > > >>>> causes a warning to be issued. However, no warnings are > issued after > > > > > >> the > > > > > >>>> first occurrence. This single warning describes how to enable > > > > further > > > > > >>>> warnings. > > > > > >>>> > > > > > >>>> Warning example: > > > > > >>>> > > > > > >>>> WARNING: An illegal reflective access operation has occurred > > > > > >>>> WARNING: Illegal reflective access by > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > >>>> (file:..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 > > > > > >>>> > > > > > >>>> > > > > > >>>> Unfortunately removing or disabling this warning is absolutely > > > > > >>> impossible, > > > > > >>>> it is generated by JVM and there is no option to disable it: > > > > > >>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > >>>> > > > > > >>>> > > > > > >>>> Sincerely, > > > > > >>>> Dmitriy Pavlov > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best regards, > Ivan Pavlukhin > |
Dmitriy,
> Would add opens require user to set up a longer line? I am not sure that got that question right. Could you please elaborate? пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov <[hidden email]>: > > Would add opens require user to set up a longer line? > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > > > By the way. It is interesting that Unsafe class is not the source of > > warnings. I checked (with java 10) that there is no warnings issued > > when Unsafe instance is accessed with good old reflective way. > > > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > > > > > Here is how our friends from Hazelcast tackle the problem [1]. Using > > > --add-opens as Stan proposed looks like a good option in short > > > perspective. By the way to determine all illegally accessed packages > > > we can use --illegal-access=warn, which does not deny operation but > > > only prints a warning. I guess we can found the majority of packages > > > by analyzing TC logs. > > > > > > WDYT? > > > > > > [1] > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > > > > > Flags/hacks is not a way to go for serious and mature projects like > > Ignite. > > > > We should switch to another mode - how to replace Unsafe completely. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov <[hidden email]> > > wrote: > > > > > > > > > > may become unavailable in any time. > > > > > > > > > > I remember this was discussed in 2013 that Unsafe will be removed > > soon. But > > > > > nothing is changed yet, so I hope unsafe will be available for a > > long time > > > > > (with flags/hacks/etc). > > > > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > > > > > > > > > According to warning message, there are no options at all, as > > Unsafe may > > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> wrote: > > > > > > > > > > > > > > It's fine as long as the project can be launched. I would better > > start > > > > > > > looking for Unsafe alternatives as the next step. We can't live > > with it > > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > >> > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > [hidden email]>: > > > > > > >> > > > > > > >>> Hello! > > > > > > >>> > > > > > > >>> I wonder if we could try to redirect output to null, initialize > > > > > > >> GridUnsafe > > > > > > >>> and then bring output back :) > > > > > > >>> > > > > > > >>> Regards, > > > > > > >>> -- > > > > > > >>> Ilya Kasnacheev > > > > > > >>> > > > > > > >>> > > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > > [hidden email]>: > > > > > > >>> > > > > > > >>>> Hi Ignite Developers, > > > > > > >>>> > > > > > > >>>> During the start of Ignite node under Java 11 (actually 9+) or > > > > > during > > > > > > >>> local > > > > > > >>>> development you may face with warning related to illegal > > access. > > > > > > >>>> > > > > > > >>>> You know that Ignite uses Unsafe operation for durable memory. > > > > > > >>>> > > > > > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now it > > is the > > > > > > >>> default > > > > > > >>>> for JVM. From the doc: > > > > > > >>>> permit: ... The first reflective-access operation to any such > > > > > package > > > > > > >>>> causes a warning to be issued. However, no warnings are > > issued after > > > > > > >> the > > > > > > >>>> first occurrence. This single warning describes how to enable > > > > > further > > > > > > >>>> warnings. > > > > > > >>>> > > > > > > >>>> Warning example: > > > > > > >>>> > > > > > > >>>> WARNING: An illegal reflective access operation has occurred > > > > > > >>>> WARNING: Illegal reflective access by > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > > >>>> (file:..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 > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> Unfortunately removing or disabling this warning is absolutely > > > > > > >>> impossible, > > > > > > >>>> it is generated by JVM and there is no option to disable it: > > > > > > >>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> Sincerely, > > > > > > >>>> Dmitriy Pavlov > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > -- Best regards, Ivan Pavlukhin |
Would it require a user to specify more options or use longer parameter
values if we change from -add-exports to -add-opens? Stanislav, could you prepare PR to demonstrate the idea. PR will probably answer to all questions. пт, 1 мар. 2019 г. в 15:09, Павлухин Иван <[hidden email]>: > Dmitriy, > > > Would add opens require user to set up a longer line? > > I am not sure that got that question right. Could you please elaborate? > > пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov <[hidden email]>: > > > > Would add opens require user to set up a longer line? > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > > > > > By the way. It is interesting that Unsafe class is not the source of > > > warnings. I checked (with java 10) that there is no warnings issued > > > when Unsafe instance is accessed with good old reflective way. > > > > > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > > > > > > > Here is how our friends from Hazelcast tackle the problem [1]. Using > > > > --add-opens as Stan proposed looks like a good option in short > > > > perspective. By the way to determine all illegally accessed packages > > > > we can use --illegal-access=warn, which does not deny operation but > > > > only prints a warning. I guess we can found the majority of packages > > > > by analyzing TC logs. > > > > > > > > WDYT? > > > > > > > > [1] > > > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > > > > > > > Flags/hacks is not a way to go for serious and mature projects like > > > Ignite. > > > > > We should switch to another mode - how to replace Unsafe > completely. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov <[hidden email] > > > > > wrote: > > > > > > > > > > > > may become unavailable in any time. > > > > > > > > > > > > I remember this was discussed in 2013 that Unsafe will be removed > > > soon. But > > > > > > nothing is changed yet, so I hope unsafe will be available for a > > > long time > > > > > > (with flags/hacks/etc). > > > > > > > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > > > > > > > > > > > According to warning message, there are no options at all, as > > > Unsafe may > > > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> > wrote: > > > > > > > > > > > > > > > > It's fine as long as the project can be launched. I would > better > > > start > > > > > > > > looking for Unsafe alternatives as the next step. We can't > live > > > with it > > > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > > > > > - > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > > > [hidden email]> > > > > > > > wrote: > > > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > > >> > > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > > [hidden email]>: > > > > > > > >> > > > > > > > >>> Hello! > > > > > > > >>> > > > > > > > >>> I wonder if we could try to redirect output to null, > initialize > > > > > > > >> GridUnsafe > > > > > > > >>> and then bring output back :) > > > > > > > >>> > > > > > > > >>> Regards, > > > > > > > >>> -- > > > > > > > >>> Ilya Kasnacheev > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > > > [hidden email]>: > > > > > > > >>> > > > > > > > >>>> Hi Ignite Developers, > > > > > > > >>>> > > > > > > > >>>> During the start of Ignite node under Java 11 (actually > 9+) or > > > > > > during > > > > > > > >>> local > > > > > > > >>>> development you may face with warning related to illegal > > > access. > > > > > > > >>>> > > > > > > > >>>> You know that Ignite uses Unsafe operation for durable > memory. > > > > > > > >>>> > > > > > > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now > it > > > is the > > > > > > > >>> default > > > > > > > >>>> for JVM. From the doc: > > > > > > > >>>> permit: ... The first reflective-access operation to any > such > > > > > > package > > > > > > > >>>> causes a warning to be issued. However, no warnings are > > > issued after > > > > > > > >> the > > > > > > > >>>> first occurrence. This single warning describes how to > enable > > > > > > further > > > > > > > >>>> warnings. > > > > > > > >>>> > > > > > > > >>>> Warning example: > > > > > > > >>>> > > > > > > > >>>> WARNING: An illegal reflective access operation has > occurred > > > > > > > >>>> WARNING: Illegal reflective access by > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > > > >>>> (file:..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 > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> Unfortunately removing or disabling this warning is > absolutely > > > > > > > >>> impossible, > > > > > > > >>>> it is generated by JVM and there is no option to disable > it: > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>> > > > > > > > >> > > > > > > > > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> Sincerely, > > > > > > > >>>> Dmitriy Pavlov > > > > > > > >>>> > > > > > > > >>> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > -- > Best regards, > Ivan Pavlukhin > |
Dmitriy,
I am a little bit confused by statement that "user should specify options". I thought that we can setup all needed variables in our startup scripts. Or are you talking about library case? And answering the question. Yes, more options will be needed. --add-exports makes not exported packages from some module visible to other specified modules. --add-opens allows reflective access to non-public members in other module packages (they call it "deep reflection"). Of course we should check everything carefully during implementation. пт, 1 мар. 2019 г. в 22:26, Dmitriy Pavlov <[hidden email]>: > > Would it require a user to specify more options or use longer parameter > values if we change from -add-exports to -add-opens? > > Stanislav, could you prepare PR to demonstrate the idea. PR will probably > answer to all questions. > > пт, 1 мар. 2019 г. в 15:09, Павлухин Иван <[hidden email]>: > > > Dmitriy, > > > > > Would add opens require user to set up a longer line? > > > > I am not sure that got that question right. Could you please elaborate? > > > > пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov <[hidden email]>: > > > > > > Would add opens require user to set up a longer line? > > > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > > > > > > > By the way. It is interesting that Unsafe class is not the source of > > > > warnings. I checked (with java 10) that there is no warnings issued > > > > when Unsafe instance is accessed with good old reflective way. > > > > > > > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > > > > > > > > > Here is how our friends from Hazelcast tackle the problem [1]. Using > > > > > --add-opens as Stan proposed looks like a good option in short > > > > > perspective. By the way to determine all illegally accessed packages > > > > > we can use --illegal-access=warn, which does not deny operation but > > > > > only prints a warning. I guess we can found the majority of packages > > > > > by analyzing TC logs. > > > > > > > > > > WDYT? > > > > > > > > > > [1] > > > > > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > > > > > > > > > Flags/hacks is not a way to go for serious and mature projects like > > > > Ignite. > > > > > > We should switch to another mode - how to replace Unsafe > > completely. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov <[hidden email] > > > > > > > wrote: > > > > > > > > > > > > > > may become unavailable in any time. > > > > > > > > > > > > > > I remember this was discussed in 2013 that Unsafe will be removed > > > > soon. But > > > > > > > nothing is changed yet, so I hope unsafe will be available for a > > > > long time > > > > > > > (with flags/hacks/etc). > > > > > > > > > > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov <[hidden email]>: > > > > > > > > > > > > > > > According to warning message, there are no options at all, as > > > > Unsafe may > > > > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email]> > > wrote: > > > > > > > > > > > > > > > > > > It's fine as long as the project can be launched. I would > > better > > > > start > > > > > > > > > looking for Unsafe alternatives as the next step. We can't > > live > > > > with it > > > > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > > > > > > > - > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > > > > [hidden email]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > > > >> > > > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > > > [hidden email]>: > > > > > > > > >> > > > > > > > > >>> Hello! > > > > > > > > >>> > > > > > > > > >>> I wonder if we could try to redirect output to null, > > initialize > > > > > > > > >> GridUnsafe > > > > > > > > >>> and then bring output back :) > > > > > > > > >>> > > > > > > > > >>> Regards, > > > > > > > > >>> -- > > > > > > > > >>> Ilya Kasnacheev > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > > > > [hidden email]>: > > > > > > > > >>> > > > > > > > > >>>> Hi Ignite Developers, > > > > > > > > >>>> > > > > > > > > >>>> During the start of Ignite node under Java 11 (actually > > 9+) or > > > > > > > during > > > > > > > > >>> local > > > > > > > > >>>> development you may face with warning related to illegal > > > > access. > > > > > > > > >>>> > > > > > > > > >>>> You know that Ignite uses Unsafe operation for durable > > memory. > > > > > > > > >>>> > > > > > > > > >>>> Accessing to Unsafe requires --illegal-access=permit (Now > > it > > > > is the > > > > > > > > >>> default > > > > > > > > >>>> for JVM. From the doc: > > > > > > > > >>>> permit: ... The first reflective-access operation to any > > such > > > > > > > package > > > > > > > > >>>> causes a warning to be issued. However, no warnings are > > > > issued after > > > > > > > > >> the > > > > > > > > >>>> first occurrence. This single warning describes how to > > enable > > > > > > > further > > > > > > > > >>>> warnings. > > > > > > > > >>>> > > > > > > > > >>>> Warning example: > > > > > > > > >>>> > > > > > > > > >>>> WARNING: An illegal reflective access operation has > > occurred > > > > > > > > >>>> WARNING: Illegal reflective access by > > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > > > > >>>> (file:..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 > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> Unfortunately removing or disabling this warning is > > absolutely > > > > > > > > >>> impossible, > > > > > > > > >>>> it is generated by JVM and there is no option to disable > > it: > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> Sincerely, > > > > > > > > >>>> Dmitriy Pavlov > > > > > > > > >>>> > > > > > > > > >>> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > -- Best regards, Ivan Pavlukhin |
In a standalone mode user have to specify options. He or she may use
application templates to simplify launch just like https://github.com/apache/ignite/tree/master/examples#running-examples-on-jdk-91011 but it is anyway required. As a user in the past (and currently) I may say: Ignite-based (or any other grid-based) soft is often developed in IDEA in the same process with server nodes. Ignite.sh (or another grid node launcher) is used in prod, but not for dev. сб, 2 мар. 2019 г. в 10:01, Павлухин Иван <[hidden email]>: > Dmitriy, > > I am a little bit confused by statement that "user should specify > options". I thought that we can setup all needed variables in our > startup scripts. Or are you talking about library case? > > And answering the question. Yes, more options will be needed. > --add-exports makes not exported packages from some module visible to > other specified modules. > --add-opens allows reflective access to non-public members in other > module packages (they call it "deep reflection"). > > Of course we should check everything carefully during implementation. > > пт, 1 мар. 2019 г. в 22:26, Dmitriy Pavlov <[hidden email]>: > > > > Would it require a user to specify more options or use longer parameter > > values if we change from -add-exports to -add-opens? > > > > Stanislav, could you prepare PR to demonstrate the idea. PR will probably > > answer to all questions. > > > > пт, 1 мар. 2019 г. в 15:09, Павлухин Иван <[hidden email]>: > > > > > Dmitriy, > > > > > > > Would add opens require user to set up a longer line? > > > > > > I am not sure that got that question right. Could you please elaborate? > > > > > > пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov <[hidden email]>: > > > > > > > > Would add opens require user to set up a longer line? > > > > > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > > > > > > > > > By the way. It is interesting that Unsafe class is not the source > of > > > > > warnings. I checked (with java 10) that there is no warnings issued > > > > > when Unsafe instance is accessed with good old reflective way. > > > > > > > > > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > > > > > > > > > > > Here is how our friends from Hazelcast tackle the problem [1]. > Using > > > > > > --add-opens as Stan proposed looks like a good option in short > > > > > > perspective. By the way to determine all illegally accessed > packages > > > > > > we can use --illegal-access=warn, which does not deny operation > but > > > > > > only prints a warning. I guess we can found the majority of > packages > > > > > > by analyzing TC logs. > > > > > > > > > > > > WDYT? > > > > > > > > > > > > [1] > > > > > > > > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > > > > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > > > > > > > > > > > Flags/hacks is not a way to go for serious and mature projects > like > > > > > Ignite. > > > > > > > We should switch to another mode - how to replace Unsafe > > > completely. > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov < > [hidden email] > > > > > > > > > wrote: > > > > > > > > > > > > > > > > may become unavailable in any time. > > > > > > > > > > > > > > > > I remember this was discussed in 2013 that Unsafe will be > removed > > > > > soon. But > > > > > > > > nothing is changed yet, so I hope unsafe will be available > for a > > > > > long time > > > > > > > > (with flags/hacks/etc). > > > > > > > > > > > > > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov < > [hidden email]>: > > > > > > > > > > > > > > > > > According to warning message, there are no options at all, > as > > > > > Unsafe may > > > > > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email] > > > > > wrote: > > > > > > > > > > > > > > > > > > > > It's fine as long as the project can be launched. I would > > > better > > > > > start > > > > > > > > > > looking for Unsafe alternatives as the next step. We > can't > > > live > > > > > with it > > > > > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > > > > > [hidden email]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > > > > >> > > > > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > > > > [hidden email]>: > > > > > > > > > >> > > > > > > > > > >>> Hello! > > > > > > > > > >>> > > > > > > > > > >>> I wonder if we could try to redirect output to null, > > > initialize > > > > > > > > > >> GridUnsafe > > > > > > > > > >>> and then bring output back :) > > > > > > > > > >>> > > > > > > > > > >>> Regards, > > > > > > > > > >>> -- > > > > > > > > > >>> Ilya Kasnacheev > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > > > > > [hidden email]>: > > > > > > > > > >>> > > > > > > > > > >>>> Hi Ignite Developers, > > > > > > > > > >>>> > > > > > > > > > >>>> During the start of Ignite node under Java 11 > (actually > > > 9+) or > > > > > > > > during > > > > > > > > > >>> local > > > > > > > > > >>>> development you may face with warning related to > illegal > > > > > access. > > > > > > > > > >>>> > > > > > > > > > >>>> You know that Ignite uses Unsafe operation for durable > > > memory. > > > > > > > > > >>>> > > > > > > > > > >>>> Accessing to Unsafe requires --illegal-access=permit > (Now > > > it > > > > > is the > > > > > > > > > >>> default > > > > > > > > > >>>> for JVM. From the doc: > > > > > > > > > >>>> permit: ... The first reflective-access operation to > any > > > such > > > > > > > > package > > > > > > > > > >>>> causes a warning to be issued. However, no warnings > are > > > > > issued after > > > > > > > > > >> the > > > > > > > > > >>>> first occurrence. This single warning describes how to > > > enable > > > > > > > > further > > > > > > > > > >>>> warnings. > > > > > > > > > >>>> > > > > > > > > > >>>> Warning example: > > > > > > > > > >>>> > > > > > > > > > >>>> WARNING: An illegal reflective access operation has > > > occurred > > > > > > > > > >>>> WARNING: Illegal reflective access by > > > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > > > > > >>>> (file:..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 > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> Unfortunately removing or disabling this warning is > > > absolutely > > > > > > > > > >>> impossible, > > > > > > > > > >>>> it is generated by JVM and there is no option to > disable > > > it: > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> Sincerely, > > > > > > > > > >>>> Dmitriy Pavlov > > > > > > > > > >>>> > > > > > > > > > >>> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > -- > Best regards, > Ivan Pavlukhin > |
Dmitriy,
Thank you for details. Yes it looks really troublesome to start Ignite development with Java 9+. I am not happy to say that but even more hacky workarounds could help us. In short term. I will try to do an exercise of setting up development environment from scratch to feel the real situation. сб, 2 мар. 2019 г. в 20:39, Dmitriy Pavlov <[hidden email]>: > > In a standalone mode user have to specify options. He or she may use > application templates to simplify launch just like > https://github.com/apache/ignite/tree/master/examples#running-examples-on-jdk-91011 > but > it is anyway required. > > As a user in the past (and currently) I may say: Ignite-based (or any other > grid-based) soft is often developed in IDEA in the same process with server > nodes. Ignite.sh (or another grid node launcher) is used in prod, but not > for dev. > > сб, 2 мар. 2019 г. в 10:01, Павлухин Иван <[hidden email]>: > > > Dmitriy, > > > > I am a little bit confused by statement that "user should specify > > options". I thought that we can setup all needed variables in our > > startup scripts. Or are you talking about library case? > > > > And answering the question. Yes, more options will be needed. > > --add-exports makes not exported packages from some module visible to > > other specified modules. > > --add-opens allows reflective access to non-public members in other > > module packages (they call it "deep reflection"). > > > > Of course we should check everything carefully during implementation. > > > > пт, 1 мар. 2019 г. в 22:26, Dmitriy Pavlov <[hidden email]>: > > > > > > Would it require a user to specify more options or use longer parameter > > > values if we change from -add-exports to -add-opens? > > > > > > Stanislav, could you prepare PR to demonstrate the idea. PR will probably > > > answer to all questions. > > > > > > пт, 1 мар. 2019 г. в 15:09, Павлухин Иван <[hidden email]>: > > > > > > > Dmitriy, > > > > > > > > > Would add opens require user to set up a longer line? > > > > > > > > I am not sure that got that question right. Could you please elaborate? > > > > > > > > пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov <[hidden email]>: > > > > > > > > > > Would add opens require user to set up a longer line? > > > > > > > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > > > > > > > > > > > By the way. It is interesting that Unsafe class is not the source > > of > > > > > > warnings. I checked (with java 10) that there is no warnings issued > > > > > > when Unsafe instance is accessed with good old reflective way. > > > > > > > > > > > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > > > > > > > > > > > > > Here is how our friends from Hazelcast tackle the problem [1]. > > Using > > > > > > > --add-opens as Stan proposed looks like a good option in short > > > > > > > perspective. By the way to determine all illegally accessed > > packages > > > > > > > we can use --illegal-access=warn, which does not deny operation > > but > > > > > > > only prints a warning. I guess we can found the majority of > > packages > > > > > > > by analyzing TC logs. > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > > > > > > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > > > > > > > > > > > > > Flags/hacks is not a way to go for serious and mature projects > > like > > > > > > Ignite. > > > > > > > > We should switch to another mode - how to replace Unsafe > > > > completely. > > > > > > > > > > > > > > > > - > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov < > > [hidden email] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > may become unavailable in any time. > > > > > > > > > > > > > > > > > > I remember this was discussed in 2013 that Unsafe will be > > removed > > > > > > soon. But > > > > > > > > > nothing is changed yet, so I hope unsafe will be available > > for a > > > > > > long time > > > > > > > > > (with flags/hacks/etc). > > > > > > > > > > > > > > > > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov < > > [hidden email]>: > > > > > > > > > > > > > > > > > > > According to warning message, there are no options at all, > > as > > > > > > Unsafe may > > > > > > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email] > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > It's fine as long as the project can be launched. I would > > > > better > > > > > > start > > > > > > > > > > > looking for Unsafe alternatives as the next step. We > > can't > > > > live > > > > > > with it > > > > > > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > > > > > > [hidden email]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > > > > > >> > > > > > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > > > > > [hidden email]>: > > > > > > > > > > >> > > > > > > > > > > >>> Hello! > > > > > > > > > > >>> > > > > > > > > > > >>> I wonder if we could try to redirect output to null, > > > > initialize > > > > > > > > > > >> GridUnsafe > > > > > > > > > > >>> and then bring output back :) > > > > > > > > > > >>> > > > > > > > > > > >>> Regards, > > > > > > > > > > >>> -- > > > > > > > > > > >>> Ilya Kasnacheev > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > > > > > > [hidden email]>: > > > > > > > > > > >>> > > > > > > > > > > >>>> Hi Ignite Developers, > > > > > > > > > > >>>> > > > > > > > > > > >>>> During the start of Ignite node under Java 11 > > (actually > > > > 9+) or > > > > > > > > > during > > > > > > > > > > >>> local > > > > > > > > > > >>>> development you may face with warning related to > > illegal > > > > > > access. > > > > > > > > > > >>>> > > > > > > > > > > >>>> You know that Ignite uses Unsafe operation for durable > > > > memory. > > > > > > > > > > >>>> > > > > > > > > > > >>>> Accessing to Unsafe requires --illegal-access=permit > > (Now > > > > it > > > > > > is the > > > > > > > > > > >>> default > > > > > > > > > > >>>> for JVM. From the doc: > > > > > > > > > > >>>> permit: ... The first reflective-access operation to > > any > > > > such > > > > > > > > > package > > > > > > > > > > >>>> causes a warning to be issued. However, no warnings > > are > > > > > > issued after > > > > > > > > > > >> the > > > > > > > > > > >>>> first occurrence. This single warning describes how to > > > > enable > > > > > > > > > further > > > > > > > > > > >>>> warnings. > > > > > > > > > > >>>> > > > > > > > > > > >>>> Warning example: > > > > > > > > > > >>>> > > > > > > > > > > >>>> WARNING: An illegal reflective access operation has > > > > occurred > > > > > > > > > > >>>> WARNING: Illegal reflective access by > > > > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > > > > > > >>>> (file:..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 > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> Unfortunately removing or disabling this warning is > > > > absolutely > > > > > > > > > > >>> impossible, > > > > > > > > > > >>>> it is generated by JVM and there is no option to > > disable > > > > it: > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> Sincerely, > > > > > > > > > > >>>> Dmitriy Pavlov > > > > > > > > > > >>>> > > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Best regards, > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > -- Best regards, Ivan Pavlukhin |
I did an exercise setting up a project which uses maven dependency to
ignite-core module. And it seems that it is not practical to simply add dependency section to pom, instruction is needed to avoid surprises. Also I succeed in creating a java agent which effectively allows to access all packages of other modules [1]. It is really a hack, but perhaps it can be useful. To be honest I adopted a sample found in the Internet [2] because it is outdated. [1] https://gist.github.com/pavlukhin/7e6740504af099cc86d67c976f1e9bee [2] https://gist.github.com/raphw/91c81b8afdfd76ccfd87508a0af0e8bb вс, 3 мар. 2019 г. в 09:01, Павлухин Иван <[hidden email]>: > > Dmitriy, > > Thank you for details. Yes it looks really troublesome to start Ignite > development with Java 9+. I am not happy to say that but even more > hacky workarounds could help us. In short term. > > I will try to do an exercise of setting up development environment > from scratch to feel the real situation. > > сб, 2 мар. 2019 г. в 20:39, Dmitriy Pavlov <[hidden email]>: > > > > In a standalone mode user have to specify options. He or she may use > > application templates to simplify launch just like > > https://github.com/apache/ignite/tree/master/examples#running-examples-on-jdk-91011 > > but > > it is anyway required. > > > > As a user in the past (and currently) I may say: Ignite-based (or any other > > grid-based) soft is often developed in IDEA in the same process with server > > nodes. Ignite.sh (or another grid node launcher) is used in prod, but not > > for dev. > > > > сб, 2 мар. 2019 г. в 10:01, Павлухин Иван <[hidden email]>: > > > > > Dmitriy, > > > > > > I am a little bit confused by statement that "user should specify > > > options". I thought that we can setup all needed variables in our > > > startup scripts. Or are you talking about library case? > > > > > > And answering the question. Yes, more options will be needed. > > > --add-exports makes not exported packages from some module visible to > > > other specified modules. > > > --add-opens allows reflective access to non-public members in other > > > module packages (they call it "deep reflection"). > > > > > > Of course we should check everything carefully during implementation. > > > > > > пт, 1 мар. 2019 г. в 22:26, Dmitriy Pavlov <[hidden email]>: > > > > > > > > Would it require a user to specify more options or use longer parameter > > > > values if we change from -add-exports to -add-opens? > > > > > > > > Stanislav, could you prepare PR to demonstrate the idea. PR will probably > > > > answer to all questions. > > > > > > > > пт, 1 мар. 2019 г. в 15:09, Павлухин Иван <[hidden email]>: > > > > > > > > > Dmitriy, > > > > > > > > > > > Would add opens require user to set up a longer line? > > > > > > > > > > I am not sure that got that question right. Could you please elaborate? > > > > > > > > > > пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov <[hidden email]>: > > > > > > > > > > > > Would add opens require user to set up a longer line? > > > > > > > > > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > > > > > > > > > > > > > By the way. It is interesting that Unsafe class is not the source > > > of > > > > > > > warnings. I checked (with java 10) that there is no warnings issued > > > > > > > when Unsafe instance is accessed with good old reflective way. > > > > > > > > > > > > > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван <[hidden email]>: > > > > > > > > > > > > > > > > Here is how our friends from Hazelcast tackle the problem [1]. > > > Using > > > > > > > > --add-opens as Stan proposed looks like a good option in short > > > > > > > > perspective. By the way to determine all illegally accessed > > > packages > > > > > > > > we can use --illegal-access=warn, which does not deny operation > > > but > > > > > > > > only prints a warning. I guess we can found the majority of > > > packages > > > > > > > > by analyzing TC logs. > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > > > > > > > > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email]>: > > > > > > > > > > > > > > > > > > Flags/hacks is not a way to go for serious and mature projects > > > like > > > > > > > Ignite. > > > > > > > > > We should switch to another mode - how to replace Unsafe > > > > > completely. > > > > > > > > > > > > > > > > > > - > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov < > > > [hidden email] > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > may become unavailable in any time. > > > > > > > > > > > > > > > > > > > > I remember this was discussed in 2013 that Unsafe will be > > > removed > > > > > > > soon. But > > > > > > > > > > nothing is changed yet, so I hope unsafe will be available > > > for a > > > > > > > long time > > > > > > > > > > (with flags/hacks/etc). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov < > > > [hidden email]>: > > > > > > > > > > > > > > > > > > > > > According to warning message, there are no options at all, > > > as > > > > > > > Unsafe may > > > > > > > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda <[hidden email] > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > It's fine as long as the project can be launched. I would > > > > > better > > > > > > > start > > > > > > > > > > > > looking for Unsafe alternatives as the next step. We > > > can't > > > > > live > > > > > > > with it > > > > > > > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > > > > > > > [hidden email]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > > > > > > >> > > > > > > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > > > > > > [hidden email]>: > > > > > > > > > > > >> > > > > > > > > > > > >>> Hello! > > > > > > > > > > > >>> > > > > > > > > > > > >>> I wonder if we could try to redirect output to null, > > > > > initialize > > > > > > > > > > > >> GridUnsafe > > > > > > > > > > > >>> and then bring output back :) > > > > > > > > > > > >>> > > > > > > > > > > > >>> Regards, > > > > > > > > > > > >>> -- > > > > > > > > > > > >>> Ilya Kasnacheev > > > > > > > > > > > >>> > > > > > > > > > > > >>> > > > > > > > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > > > > > > > [hidden email]>: > > > > > > > > > > > >>> > > > > > > > > > > > >>>> Hi Ignite Developers, > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> During the start of Ignite node under Java 11 > > > (actually > > > > > 9+) or > > > > > > > > > > during > > > > > > > > > > > >>> local > > > > > > > > > > > >>>> development you may face with warning related to > > > illegal > > > > > > > access. > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> You know that Ignite uses Unsafe operation for durable > > > > > memory. > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> Accessing to Unsafe requires --illegal-access=permit > > > (Now > > > > > it > > > > > > > is the > > > > > > > > > > > >>> default > > > > > > > > > > > >>>> for JVM. From the doc: > > > > > > > > > > > >>>> permit: ... The first reflective-access operation to > > > any > > > > > such > > > > > > > > > > package > > > > > > > > > > > >>>> causes a warning to be issued. However, no warnings > > > are > > > > > > > issued after > > > > > > > > > > > >> the > > > > > > > > > > > >>>> first occurrence. This single warning describes how to > > > > > enable > > > > > > > > > > further > > > > > > > > > > > >>>> warnings. > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> Warning example: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> WARNING: An illegal reflective access operation has > > > > > occurred > > > > > > > > > > > >>>> WARNING: Illegal reflective access by > > > > > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > > > > > > > >>>> (file:..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 > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> Unfortunately removing or disabling this warning is > > > > > absolutely > > > > > > > > > > > >>> impossible, > > > > > > > > > > > >>>> it is generated by JVM and there is no option to > > > disable > > > > > it: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>> > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> Sincerely, > > > > > > > > > > > >>>> Dmitriy Pavlov > > > > > > > > > > > >>>> > > > > > > > > > > > >>> > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Best regards, > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin |
Looks promising. Is it possible to run this code from main? Or it has to be
an agent. вс, 3 мар. 2019 г., 20:26 Павлухин Иван <[hidden email]>: > I did an exercise setting up a project which uses maven dependency to > ignite-core module. And it seems that it is not practical to simply > add dependency section to pom, instruction is needed to avoid > surprises. > > Also I succeed in creating a java agent which effectively allows to > access all packages of other modules [1]. It is really a hack, but > perhaps it can be useful. To be honest I adopted a sample found in the > Internet [2] because it is outdated. > > [1] https://gist.github.com/pavlukhin/7e6740504af099cc86d67c976f1e9bee > [2] https://gist.github.com/raphw/91c81b8afdfd76ccfd87508a0af0e8bb > > вс, 3 мар. 2019 г. в 09:01, Павлухин Иван <[hidden email]>: > > > > Dmitriy, > > > > Thank you for details. Yes it looks really troublesome to start Ignite > > development with Java 9+. I am not happy to say that but even more > > hacky workarounds could help us. In short term. > > > > I will try to do an exercise of setting up development environment > > from scratch to feel the real situation. > > > > сб, 2 мар. 2019 г. в 20:39, Dmitriy Pavlov <[hidden email]>: > > > > > > In a standalone mode user have to specify options. He or she may use > > > application templates to simplify launch just like > > > > https://github.com/apache/ignite/tree/master/examples#running-examples-on-jdk-91011 > > > but > > > it is anyway required. > > > > > > As a user in the past (and currently) I may say: Ignite-based (or any > other > > > grid-based) soft is often developed in IDEA in the same process with > server > > > nodes. Ignite.sh (or another grid node launcher) is used in prod, but > not > > > for dev. > > > > > > сб, 2 мар. 2019 г. в 10:01, Павлухин Иван <[hidden email]>: > > > > > > > Dmitriy, > > > > > > > > I am a little bit confused by statement that "user should specify > > > > options". I thought that we can setup all needed variables in our > > > > startup scripts. Or are you talking about library case? > > > > > > > > And answering the question. Yes, more options will be needed. > > > > --add-exports makes not exported packages from some module visible to > > > > other specified modules. > > > > --add-opens allows reflective access to non-public members in other > > > > module packages (they call it "deep reflection"). > > > > > > > > Of course we should check everything carefully during implementation. > > > > > > > > пт, 1 мар. 2019 г. в 22:26, Dmitriy Pavlov <[hidden email]>: > > > > > > > > > > Would it require a user to specify more options or use longer > parameter > > > > > values if we change from -add-exports to -add-opens? > > > > > > > > > > Stanislav, could you prepare PR to demonstrate the idea. PR will > probably > > > > > answer to all questions. > > > > > > > > > > пт, 1 мар. 2019 г. в 15:09, Павлухин Иван <[hidden email]>: > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > > Would add opens require user to set up a longer line? > > > > > > > > > > > > I am not sure that got that question right. Could you please > elaborate? > > > > > > > > > > > > пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov <[hidden email]>: > > > > > > > > > > > > > > Would add opens require user to set up a longer line? > > > > > > > > > > > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <[hidden email]>: > > > > > > > > > > > > > > > By the way. It is interesting that Unsafe class is not the > source > > > > of > > > > > > > > warnings. I checked (with java 10) that there is no warnings > issued > > > > > > > > when Unsafe instance is accessed with good old reflective > way. > > > > > > > > > > > > > > > > пт, 1 мар. 2019 г. в 08:05, Павлухин Иван < > [hidden email]>: > > > > > > > > > > > > > > > > > > Here is how our friends from Hazelcast tackle the problem > [1]. > > > > Using > > > > > > > > > --add-opens as Stan proposed looks like a good option in > short > > > > > > > > > perspective. By the way to determine all illegally accessed > > > > packages > > > > > > > > > we can use --illegal-access=warn, which does not deny > operation > > > > but > > > > > > > > > only prints a warning. I guess we can found the majority of > > > > packages > > > > > > > > > by analyzing TC logs. > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png > > > > > > > > > > > > > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <[hidden email] > >: > > > > > > > > > > > > > > > > > > > > Flags/hacks is not a way to go for serious and mature > projects > > > > like > > > > > > > > Ignite. > > > > > > > > > > We should switch to another mode - how to replace Unsafe > > > > > > completely. > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov < > > > > [hidden email] > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > may become unavailable in any time. > > > > > > > > > > > > > > > > > > > > > > I remember this was discussed in 2013 that Unsafe will > be > > > > removed > > > > > > > > soon. But > > > > > > > > > > > nothing is changed yet, so I hope unsafe will be > available > > > > for a > > > > > > > > long time > > > > > > > > > > > (with flags/hacks/etc). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > чт, 28 февр. 2019 г. в 09:11, Petr Ivanov < > > > > [hidden email]>: > > > > > > > > > > > > > > > > > > > > > > > According to warning message, there are no options > at all, > > > > as > > > > > > > > Unsafe may > > > > > > > > > > > > become unavailable in any time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 27 Feb 2019, at 22:53, Denis Magda < > [hidden email] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > It's fine as long as the project can be launched. > I would > > > > > > better > > > > > > > > start > > > > > > > > > > > > > looking for Unsafe alternatives as the next step. > We > > > > can't > > > > > > live > > > > > > > > with it > > > > > > > > > > > > > forever, the time to phase it out has come :) > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov < > > > > > > > > [hidden email]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > > > > > > > >> > > > > > > > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > > > > > > > [hidden email]>: > > > > > > > > > > > > >> > > > > > > > > > > > > >>> Hello! > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> I wonder if we could try to redirect output to > null, > > > > > > initialize > > > > > > > > > > > > >> GridUnsafe > > > > > > > > > > > > >>> and then bring output back :) > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> Regards, > > > > > > > > > > > > >>> -- > > > > > > > > > > > > >>> Ilya Kasnacheev > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov < > > > > > > > > [hidden email]>: > > > > > > > > > > > > >>> > > > > > > > > > > > > >>>> Hi Ignite Developers, > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> During the start of Ignite node under Java 11 > > > > (actually > > > > > > 9+) or > > > > > > > > > > > during > > > > > > > > > > > > >>> local > > > > > > > > > > > > >>>> development you may face with warning related to > > > > illegal > > > > > > > > access. > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> You know that Ignite uses Unsafe operation for > durable > > > > > > memory. > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> Accessing to Unsafe requires > --illegal-access=permit > > > > (Now > > > > > > it > > > > > > > > is the > > > > > > > > > > > > >>> default > > > > > > > > > > > > >>>> for JVM. From the doc: > > > > > > > > > > > > >>>> permit: ... The first reflective-access > operation to > > > > any > > > > > > such > > > > > > > > > > > package > > > > > > > > > > > > >>>> causes a warning to be issued. However, no > warnings > > > > are > > > > > > > > issued after > > > > > > > > > > > > >> the > > > > > > > > > > > > >>>> first occurrence. This single warning describes > how to > > > > > > enable > > > > > > > > > > > further > > > > > > > > > > > > >>>> warnings. > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> Warning example: > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> WARNING: An illegal reflective access operation > has > > > > > > occurred > > > > > > > > > > > > >>>> WARNING: Illegal reflective access by > > > > > > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2 > > > > > > > > > > > > >>>> (file:..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 > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> Unfortunately removing or disabling this > warning is > > > > > > absolutely > > > > > > > > > > > > >>> impossible, > > > > > > > > > > > > >>>> it is generated by JVM and there is no option to > > > > disable > > > > > > it: > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> Sincerely, > > > > > > > > > > > > >>>> Dmitriy Pavlov > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Best regards, > > > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best regards, > Ivan Pavlukhin > |
Free forum by Nabble | Edit this page |