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 <dpav...@apache.org>: > > 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, Павлухин Иван <vololo...@gmail.com>: > > > 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 <dpav...@apache.org>: > > > > > > Would add opens require user to set up a longer line? > > > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <vololo...@gmail.com>: > > > > > > > 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, Павлухин Иван <vololo...@gmail.com>: > > > > > > > > > > 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 <dma...@apache.org>: > > > > > > > > > > > > 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 <dpav...@apache.org > > > > > > > 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 <mr.wei...@gmail.com>: > > > > > > > > > > > > > > > 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 <dma...@apache.org> > > 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 < > > > > dpav...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > >> Sure, we could try this option. > > > > > > > > >> > > > > > > > > >> ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev < > > > > > > > > ilya.kasnach...@gmail.com>: > > > > > > > > >> > > > > > > > > >>> 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 < > > > > dpav...@apache.org>: > > > > > > > > >>> > > > > > > > > >>>> 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
