Pattern Matching in Switches and Security Manager Deprecation - Inside Java Newscast #5

#Java #OpenJDK #JDK
JEP 406, which is a candidate for Java 17, introduced pattern matching in `switch` statements and expressions, introduces guarded patterns, and improves null handling. Then we need to talk about JEP 411's deprecation of the security manager.

⎯⎯⎯⎯⎯⎯ Chapters ⎯⎯⎯⎯⎯⎯
0:00 Intro
0:42 Pattern Matching and Switches
3:19 Security Manager Deprecation
3:54 Security Manager Deprecation - What will happen in Java17?
5:12 Security Manager Deprecation - Will this break projects?
6:47 Security Manager Deprecation - What will happen after Java 17?
7:29 Security Manager Deprecation - Why the (eventual) removal?
Mailing list conversations:
8:57 Security Manager Deprecation - What about other use cases?
10:02 Outro

[mustafailikkan]

Thanks for starting this newscast. These are short and sweet videos which helps improving my awareness about Java and jvm technologies.

[SourabhBhat]

I really enjoy watching the Inside Java Newscast. Very entertaining and informative. :)

[jannishoffmann]

Great editing and thanks for covering this in a calm manner (some people on the internet have a little to strong feelings on JEP 411).

[ubaidurrehman]

really nice. Started my day with this vid.

[TheDragShot]

Jeez, a lot of convoluted updates are being added lately, they sound a lot of fun to use tho. Good thing I'm not the one in charge of implementing/maintaining all of those features, otherwise I would be sweating more than hyped.

I have mixed feelings about the removal of SecurityManager. I don't remember using it too often, although I do remember maintaining some projects in the past that did use it. At least there should be plenty of time to remove those calls, so it's not that bad. However, I think those use-cases that are not related to security should be thoroughly reviewed and official support for them should be implemented before even a deprecation warning is issued, I've never been a fan of stacking lots and lots of libraries in order to cover functionality that vanilla Java could easily cover on its own. That's too JavaScript for my taste.

Btw do you guys know of any JEP covering the sandboxing of unsafe user-supplied code? With stuff like Nashorn long gone I was wondering if there was any alternative for user scripting that wouldn't involve adding any fancy libraries with a dozen of dependencies.

[zhcha]

Great, but i hope the video could enable auto-generated ENG subtitle. thanks~

[mhatano]

Preventing plugins (no matter which is trusted or untrusted) from calling System.exit() is very much security and system stability thing from framework point of view. Pro-JEP411 camp members always say "it is not a security" but, yes it is. This is the starting point about this discussion. What is "security"?

[JairoGrateron]

Me parece muy bien la futura eliminación del Security Manager, es de poca utilidad y agrega capas que hacen lento las aplicaciones java. En un mundo de containers Java debe relegar esa responsabilidad de seguridad al SO, como lo hacen los demás lenguajes de programación y centrarse en agregar funcionalidades al programador para ser más ágil.