If we need to get access to something like this, using something more specific like "--add-opens java.desktop/sun.awt=ALL-UNNAMED" is AFAIK a much better way.
Jan On Sun, Mar 28, 2021 at 5:03 PM Bläsing, Matthias <mblaes...@doppel-helix.eu> wrote: > Hi Patrik, > > Am 28.03.2021 um 13:01 schrieb Patrik Karlström: > > I noticed that kwin did not apply my window rules any more, not for > > NetBeans nor for my platform application. > > > > pata@xps:~/tmp$ xprop WM_CLASS > > WM_CLASS(STRING) = "java-lang-Thread", "java-lang-Thread" > > > > That was with 16.0.0.fx-zulu, switching to Java 11 works fine (so did > 15): > > > > pata@xps:~/tmp$ xprop WM_CLASS > > WM_CLASS(STRING) = "Mapton", "Mapton" > > I suspect that you see: > > https://openjdk.java.net/jeps/396 > > combined with: > > https://bugs.openjdk.java.net/browse/JDK-6528430 > > (yes the issue was created 14! years ago!) > > Please test if adding "--illegal-access=permit" to the JVM launch flags > helps. JVM flags supplied via config or CLI need to be prefixed with > "-J", so the above becomes "-J--illegal-access=permit". > > I tested on windows with "--illegal-access=debug" like this: > > C:\LokaleProgramme\netbeans\bin\netbeans64.exe -J--illegal-access=debug > > And got this report: > > WARNING: Illegal reflective access by > org.netbeans.core.output2.FileMapStorage > (jar:file:/C:/LokaleProgramme/netbeans/platform/modules/org-netbeans-core-output2.jar!/) > to method java.nio.DirectByteBuffer.cleaner() > at > org.netbeans.core.output2.FileMapStorage.unmap(FileMapStorage.java:311) > at > org.netbeans.core.output2.FileMapStorage.access$400(FileMapStorage.java:38) > at > org.netbeans.core.output2.FileMapStorage$MappedBufferResource.decRefs(FileMapStorage.java:479) > at > org.netbeans.core.output2.FileMapStorage.updateContents(FileMapStorage.java:377) > at > org.netbeans.core.output2.FileMapStorage.getReadBuffer(FileMapStorage.java:341) > > As "--illegal-access" is deprecated for removal, we might need to turn > to harder methods to hack into the JDK (or convince someone to fix the > bug mentioned above). Given that we have JNA in our hands, we could try > to go throught the JNI layer to break module encapsulation (yes it is a > sledgehammer, but I don't see an alternative, which will then also work > on JDK 16). > > It seems our friends over at JetBrains face the same problem: > > https://youtrack.jetbrains.com/issue/JBR-1280 > > Before doing anything further we should see if running with > "--illegal-access=permit" helps. > > Greetings > > Matthias > > | > | > >
