NB config: disable TopSecurityManager and enable exit logging

[mbien]

Suggestion came up on apache slack to do another release without applying #3386 or #7928 but disabling TopSecurityManager instead.

this PR:

• replaces -Djava.security.manager=allow' with -DTopSecurityManager.disable=trueand-Djava.lang.Runtime.level=FINE`
• allows launching NB builds on JDK 17-24

cons:

• contrary to Remove SecurityManager layer #7928, no tests ran on JDK 24 with this config (and CI will continue testing on JDK 23 as upper bound)
• even though I run those flags since NB 23 on JDK 23, I didn't actually test it on JDK 24 (I tested the removal PR instead)
• -> current confidence level regarding JDK 24 + topsec disabled: "works on my machine"

pros:

• can be switched on again if problems are encountered

[matthiasblaesing]

Would make sense from my POV.

[mbien]

planning to merge this on monday so that it is in a few days before freeze unless told otherwise.

[eirikbakke]

Reading the discussions from #3386 this seems like a good idea. Perhaps not all of the old SecurityManager-related functionality is really necessary anymore. It will be useful to know what (if anything) breaks when we simply disable it by default for a while. (That was my understanding of the discussion, anyway.)

I'll run with TopSecurityManager.disable=true on my MacOS/OpenJDK 21 setup from now on and watch out for any issues. I see that others have done the same for a while on their own machines.

[mbien]

Reading the discussions from #3386 this seems like a good idea.

in a perfect world we would have set this for NB 24 already - but back then we couldn't since the launcher wasn't fixed yet. I have some concerns doing this so late since it pushes everything back to the very last minute but there is no time for anything else anyway at this point (+ I wished there was more discussion on the dev list threads). As long as we integrate one of the SM removal PRs early during NB 26 so that we can finally start running tests on JDK 24 and catch up so to speak.

[eirikbakke]

As long as we integrate one of the SM removal PRs early during NB 26 so that we can finally start running tests on JDK 24 and catch up so to speak.

Disabling the SecurityManager with an easily revertible flag for one release first seems like a good separate step. It's a bit of a "rip the band-aid" situation, but eventually OpenJDK will rip it for us.

I wished there was more discussion on the dev list threads

I saw the discussions myself but never quite managed to understand what the SecurityManager was doing that was essential. I just understood the part about protection from System.exit(), which seemed like something we could live without. And there seems to be a lot of other things which are mainly diagnostic in nature. Though it sounds like there are a lot of tests that break without it.

If problems do arise from this PR, I bet more people will get involved in the discussion.

[mbien]

Disabling the SecurityManager with an easily revertible flag for one release first seems like a good separate step. It's a bit of a "rip the band-aid" situation, but eventually OpenJDK will rip it for us.

I never had anything against this idea, except the timing - the consequence is that NB 25 will be released with nb-javac 24 while having CI still test on JDK 23. The only PR which did test on JDK 24 so far was #7928.

I saw the discussions myself but never quite managed to understand what the SecurityManager was doing that was essential. I just understood the part about protection from System.exit(), which seemed like something we could live without. And there seems to be a lot of other things which are mainly diagnostic in nature. Though it sounds like there are a lot of tests that break without it.

the linked PR does list a few things and discusses them / gives alternatives where applicable

[mbien]

planning to merge this on monday so that it is in a few days before freeze unless told otherwise.

saw no change requests (PR was also linked to the dev list) -> merging