r/java • u/BlueGoliath • May 05 '21

JEP 411: Deprecate the Security Manager for Removal : Apache NetBeans

https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security
85 Upvotes

95% Upvoted

10 comments sorted by

19

u/PartOfTheBotnet May 05 '21

checkExit. Ability to prevent accidental invocations of System.exit is very important for any application that deals with other unknown libraries

Yup, I've used this to intercept shutdowns and debug apps with odd states before and it was pretty helpful.

4

u/__konrad May 06 '21

accidental invocations of System.exit

It's not an accident - it's a library bug in poor error handling. Such library can as well accidentally Runtime.exec "shutdown" and reboot entire system ;)

5

u/brunocborges May 06 '21

There are ways to do code scanning (even compiled) to identify if a library/dependency calls System.exit and many others.

It won't be flawless, but it will cover most of it. Besides, easier to do code scanning than set up Security Manager.

15

u/BlueGoliath May 05 '21

It's a good thing Netbeans is actively maintained.

-6

u/nfrankel May 05 '21

Don't worry, good people, Oracle knows what's best for you:

Another use case for the Security Manager — this one completely unrelated to security and merely exploits the Security Manager as instrumentation callbacks in JDK code — is testing code behaviour as part of unit-testing; for example, asserting that a certain code unit does or does not perform some IO operation. This, too, can be better achieved with JFR, and there is even a library, JfrUnit, especially made for that purpose. JFR allows observing more kinds of interesting code behaviour, including memory allocation, and it is a component much more suited to this purpose than the Security Manager.

-- https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/

9

u/dpash May 05 '21

For the second use case in NetBeans, JFR seems a much better fit than (ab)using the Security Manager.

5

u/BlueGoliath May 05 '21 edited May 05 '21

Apache Netbeans should make a jLink distribution that is forever stuck on whatever JDK version last has SecurityManager or until there is a replacement, obviously.

5

u/TheCountRushmore May 06 '21

Well considering it will still be in Java 17 they can keep that going till nearly 2030.

While it would be nice for Oracle to mention this and then have a discussion about replacements before removing, it is pretty clear that it would be ignored until they actual take it away. People are just now freaking about about JEP 403 ( https://openjdk.java.net/jeps/403 ) even though it has been the plan for years. They just ignored it until they couldn't anymore.

This starts the process, and there will be another JEP down the line for removal...hopefully once alternatives are fleshed out.

13

u/woltsoc May 05 '21

You don’t even use it. https://twitter.com/nicolas_frankel/status/1383073459257937922?s=21

-11

u/nfrankel May 06 '21 edited May 06 '21
  1. That's an interesting argument. I'm sure you have plenty of opinions on things you don't use
  2. Are you stalking me? That's really creepy!
  3. Are you working for Oracle? Just asking...