mbien opened a new pull request, #7928: URL: https://github.com/apache/netbeans/pull/7928
JDK 24 on the horizon we will have to find a solution for the upcoming removal of the deprecated `SecurityManager` mechanism. [JEP 486](https://openjdk.org/jeps/486) is a candidate for JDK 24, PR is here https://github.com/openjdk/jdk/pull/21498 (still open) This PR is an alternative to https://github.com/apache/netbeans/pull/3386 and proposes to remove the SM layer entirely, trying to avoid additional complexity of a tracking agent. To simulate this, I am running NB 23 with `-DTopSecurityManager.disable=true -Djava.lang.Runtime.level=FINE` for several weeks now without issues, this PR goes one step further and removes the SM layer for a test build - which I tested too, but only about 10 days so far. What is SM used for? Why could we likely simply remove it? System exit blocking: - trusted dependencies should not exit JVMs! (OpenJDK essentially came to the same conclusion if you read the JEP) - there are many other ways to take down JVMs, the basic question is: is the dependency trusted or not, there is no way to simply run untrusted code today - JVM exit is trackable with `-J-Djava.lang.Runtime.level=FINE` (will log full stack trace) and also via JFR's `jdk.Shutdown` event - if something exits it can be found in the log and the issue resolved - there is no ambiguity between JVM hard crashes and faulty dependencies - problematic plugins can be removed from the portal until fixed (we have to do this anyway if something causes issues) - tested several scenarios I could come up with - e.g form designer preview windows with `EXIT_ON_CLOSE` - or debugger eval window running `System.exit(0)`) but nothing did actually exit NB - the "waiting for process to finish" window does also still work before exit swing clipboard swap: - NB swapped swing's clipboard impl by hooking into JDK's AppContext which was originally used for webstart sandboxing - this did grab `sun.awt.AppContext` and write [`TransferHandler#SandboxClipboardKey`](https://github.com/openjdk/jdk/blob/688e92e7f5febddd2935cb7f500dd3f10fbd9401/src/java.desktop/share/classes/javax/swing/TransferHandler.java#L1788-L1792) using reflection, which was only read by Swing if a SM blocked access to the system clipboard (!) - with webstart and SM removed, the clipboard swap trick will likely quit working too at some point (why would they keep this impl detail?) - we might be able to remove an add-opens here - TODO: more data needed - i tested this for over a month now and clipboard works perfectly fine so far - but I am no clipboard power user and only tested on linux File IO tracking: - tracking r/w methods gives wrong picture of the environment - big part of IO is out of process (e.g the mvn/gradle process which might be even second level background daemons) - IO heavy tasks are well known (e.g code scanning) even without method level tracking - NVMe/SSDs are pretty good at concurrent IO today - scheduling is questionable on non-mechanical drives - most of this was written when hardware was more limited and RAM / caches were small - running NB without IO task scheduling works perfectly fine for me - I can't tell a difference Tracking calls to Unsafe: - Unsafe is deprecated for removal, this problem will fix itself - switches exist, e.g: `--sun-misc-unsafe-memory-access=deny` - platform apps might be able to use JMS encapsulation to further limit reflective access -> I don't think we actually need the SM layer anymore. This gives us an opportunity to remove a layer without further complicating things with an agent requirement for everything (launcher, tests, archetypes etc). The agent rewrites bytecode by hand(!) to avoid having to bundle ASM, this could be likely solved by shading ASM till JDK 23 and using the multi-release mechanism + classfile API for 24+ (now final) but this is all extra maintenance cost which we should try to avoid if possible. Bytecode rewriting can cause followup issues e,g jumping out of methods during debugging sessions without seeing the reason for it in the source. I do think the agent impl is actually [pretty cool](https://github.com/apache/netbeans/pull/3386#issuecomment-1001446015) but I don't think everything what can be added, should be added if it is avoidable. (also please note that back then NB was still stuck on JDK 8) this is just a draft - don't panic. This likely will need to be discussed on the mailing list anyway. But feel free to give the dev build it a try. (the windows launcher might still break things since it has to be build separately unfortunately) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@netbeans.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@netbeans.apache.org For additional commands, e-mail: notifications-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
