5 ms·

SecurityManager dies not with a bang, but a whimper. The professor who taught a generally-misguided Java elective extolled the benefits of the security manager

SecurityManager dies not with a bang, but a whimper. The professor who taught a generally-misguided Java elective extolled the benefits of the security manager whenever he could. I was tremendously skeptical at the time. I'm inappropriately smug to have been proven right now, several decades later. I really want structured concurrency out of preview!! I think it helps close one of the last gaps golang has over Java in the ease-of-concurrent-programming side of things. Go makes channels and waitgroups pretty easy. I think structured concurrency is a great side-step of those primitives by actually making the higher-level tasks you use those tools to accomplish easier to write and reason about. Continuing a trend I see where go tends to have somewhat better primitives, but then obstinately does nothing with them to actually make the higher-level tasks easier to accomplish. No pinning virtual threads is huge. Finally you can virtual thread with near-wild abandon, as God intended. Love seeing Streams still getting love. I do a lot of fizzbuzz-esque interviews (the "can you code your way out of a paper bag" type screens) for my company and I think it says a lot that, in general, people who pick Java and use streams pass but people who don't use streams often get tripped up in their loop logic and fail (or, even if they don't fail per se, don't pass). It says a lot about ergonomics and intuitiveness, and also the power of the abstraction to tersely and compactly solve real problems, when a language is a big ally in interviews. And the cool thing about Java streams is that they're as powerful as Ruby's functional-style operation chaining (arr.map{}.reduce(:+) etc) but they're actually performant. I feel it also bears mentioning that people who use Ruby in these interviews, few as they are, almost always pass and do so while writing very few LOC :)

MarkMarine 2y ago
Go is the poster child for not having structured concurrency, the article that started this movement was an explicit take down of go’s concurrency primitive “go func” being dangerous. https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... I think Kotlin still leads here, and even the Java changes don’t have the same nice ergonomics you get with Kotlin’s DSL. Would love to see more tenseness from Kotlin leak into Java.
- pjmlp 2y ago
  Yet, like most Go design decisions, they will end up retrofiting what should have been there. Kotlin has the issue of being a guest language, and wanting to play in many playgrounds, eventually it will diverge as it always happens. As it is already happening, like now how will Kotlin async deal with virtual threads expectations, including writing portable code that doesn't suffer from runtime semantics, depending on the target platform.
  - MarkMarine 2y ago
    Something better than making everyone take context as the first arg in every function? It’s go’s own brute force way of function coloring, except you have to write it yourself and drag this arbitrary bag of data through every function, what a horrible stapled-on mess.
- yubblegum 2y ago
  > explicit take down of ... "go func" I stopped at "go statements are a form of goto statement." This is simply not correct. They have some diagrams and squinted and said "hey, that looks the same as a goto statement", but unfortunatley they have their diagrams wrong. "go func" will run at scheduler's pleasure, not immediately after the statement "go func..". A goto statement is a deterministic flow control directive. It will goto where you tell it.
  - MarkMarine 2y ago
    you should have read the rest of it then, because in the context of Dijkstra's famous paper [0] (that this is written in the style of) the argument here is being able to understand program flow in the programmers' mind. Your description of the go func actually makes it WORSE, because the program doesn't just go there, it goes there later. [0] https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
    - yubblegum 2y ago
bullen 2y ago
Security Manager is one of the only unique selling points of Java, to remove it (without removing it because you need it underneath) is as big of a blunder as removing Applets from browsers and replacing it with something worse: WASM without GC and then adding GC to WASM... If SVTwP is not better than NIO; Java ends with JDK 23. > Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem Because no feature added after 1.8 made sense, so nobody upgraded. They are taking decisions off the wrong data. > they are encouraged to transition to alternative sandboxing and API interception mechanisms Feel free to link to anything useful!
- oblio 2y ago
  There are plenty of places that are at least on Java 11, so I highly doubt the "no one upgraded" part.
  - bullen 2y ago
    I meant to 17 so they would see the warning.
- lief79 2y ago
  That has as much to do with Oracle lawyers and ambiguous licensing issues as anything else.
- atomicnumber3 2y ago
  Unique, sure. Selling point? I really don't think so. This idea of "safely" running untrusted code in the jvm sandbox both never materialized (constant stream of sandbox-escape vulns i've seen over the years) and also was at the wrong level - anyone doing multi-tenant code execution is doing it via things like gvisor or at the OS-level. I don't think I buy your assertion that nobody has upgraded. I know of a 3000-4000-strong eng org at a certain company that has upgraded all the way from 8 to 17 as of when i left 3 years ago. They primarily wanted the GC improvements because they translated into huge immediate efficiency gains on their workloads (huge Spark/Hadoop spend savings, and moderate savings for the non-big-data jvm workloads). I do share your lament of applets though. It would've been a way better runtime for portable/install-less/JIT-install things than the current nightmare of html/css/js/etc. But they just didn't have the browser integration - it would've needed to be more than just "look we put a drawing surface into the web browser" - and they didn't have the "window into the world" either (that's browsers). Unfortunately, it's the front door program and platform that owns the users, and that's web browsers.
raducu 2y ago
> No pinning virtual threads is huge Have ALL previous pinning scenarios been resolved, including native calls?
- atomicnumber3 2y ago
  ALL? no. but based on my read of the article's linked bit on thread pinning, it seems like it has been substantially resolved, and remaining pinning scenarios are quite rare (they mention you can look for them in JFR).
  - raducu 2y ago
    I was wondering if native calls were solved, but I don't see how those can ever be solved
    - samus 2y ago
      In the long term native calls will require a command line flag to be permitted. No matter whether they are done via FFI or JNA. By then, libraries better figure out a way to document them or to reduce using them as much as possible. A lot of off-heap memory trickery should now be possible via (unsafe of course) functions from the FFI library.
jsiepkes 2y ago
> I really want structured concurrency out of preview!! I'm guessing they thought it couldn't hurt to do another round of testing. Since OpenJDK 25 will be an LTS release, I suspect it will go out of preview in the next release.
jayd16 2y ago
I'm glad they're working on it but I still can't help but my miss async/await. In C# the API is a bit overturned for sharing a GUI thread but it does the job. Structured Concurrency makes the scopes more obvious but I'm worried about the ergonomics. What is the core use case for the design? Is it just to make collecting a set of concurrent tasks bullet proof? Are we going to see scopes abused and passed around to handle the non-happy path of "a function always ends before it's caller." It doesn't seem to service GUI programming all that well. I guess there's still Kotlin's approach but hopefully something happens on the Java side.
- atomicnumber3 2y ago
  "Is it just to make collecting a set of concurrent tasks bullet proof?" At a surface level, yeah basically. And ask anyone who's used python's multiprocessing how hard that is to actually get completely right. I don't think structured concurrency is going to be some panacea of multiprocessing at all. It's to address code you'd see in golang that's like, make a waitgroup, fire off N goroutines, wait for success and gather errors. That code is not incredibly fun in Java right now. w.r.t. async/await, imo the beauty of virtual threads is that you've no longer got function coloring, and the "await"s are free, implicit, and performant. and of course you're never precluded from using higher level application locks that have always been there, including synchronized now. Also, specifically w.r.t. gui programming, I think Java is unfortunately kind of stuck. JavaFX has been put into the back of the closet, Swing is completely ossified (though tbh I still like it), and what energy is there behind any non-electron/web GUI development anymore anyway? In a world where vscode, one of the most popular new "IDEs"/IDE platforms, is written in a frickin web browser, and mobile apps dominate a huge % of what constitutes "native" GUI development, I don't really blame Java for not prioritizing it beyond keeping Swing working on e.g. hiDPI displays and so on.
neonsunset 2y ago
> Java streams is that they're as powerful as Ruby's functional-style operation chaining (arr.map{}.reduce(:+) etc) This is not a unique Ruby feature though. Iterators are very common nowadays. Java streams have okay performance, much like .NET's LINQ you likely won't be able to use them in a really performance-sensitive code (although LINQ is improving quite a bit with each new release, overall it performs moderately to significantly faster than Java Streams, but usually slower than Rust iterators).
pjmlp 2y ago
.NET also removed their version of security manager (Code Access Security) for similar reasons. Just like I expect WebAssembly security conversation to change when folks start plugging components left and right, beyond straight compute logic.
msgilligan 2y ago
> I'm inappropriately smug to have been proven right now, several decades later. I think you were proven right at least a decade ago. As you said, this is just the final whimper.
scottlamb 2y ago
> No pinning virtual threads is huge. Finally you can virtual thread with near-wild abandon, as God intended. I see that formerly it pinned virtual threads "when it executes code inside a synchronized block or method", and "frequent pinning for long durations can harm the scalability of an application by capturing carriers". You were supposed to "avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use java.util.concurrent.locks.ReentrantLock instead." How big a problem was this in practice? On the one hand, I think "harm the scalability" is putting it mildly—if you have a whole bunch of virtual threads doing IO, only running num_cores of them at once is devastating. On the other hand, holding a lock while doing IO smells wrong. Is this really common?
- mping 2y ago
  I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized. If the performance with vthreads was much worse for some cases it would be a bit of failure
  - re-thc 2y ago
    > I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized. Those usually have company / community backing that gets it fixed. The irony is you patch the ORM and you patch the JDBC driver only to realize the database pooling library in-between is the 1 that's broken and the author refuses to fix it.
    - samus 2y ago
      Switching `synchronized` for `ReentrantLock` is possible in principle, but it makes the code harder to read and opens the door to subtle concurrency bugs. Library authors really don't want this kind of code churn for an issue that is not their fault, not their responsibility to solve, and that will get a bugfix before long that maybe even qualifies for a backport to LTS 21.
- re-thc 2y ago

MarkMarine 2y ago

Go is the poster child for not having structured concurrency, the article that started this movement was an explicit take down of go’s concurrency primitive “go func” being dangerous. https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... I think Kotlin still leads here, and even the Java changes don’t have the same nice ergonomics you get with Kotlin’s DSL. Would love to see more tenseness from Kotlin leak into Java.

pjmlp 2y ago
Yet, like most Go design decisions, they will end up retrofiting what should have been there. Kotlin has the issue of being a guest language, and wanting to play in many playgrounds, eventually it will diverge as it always happens. As it is already happening, like now how will Kotlin async deal with virtual threads expectations, including writing portable code that doesn't suffer from runtime semantics, depending on the target platform.
- MarkMarine 2y ago
  Something better than making everyone take context as the first arg in every function? It’s go’s own brute force way of function coloring, except you have to write it yourself and drag this arbitrary bag of data through every function, what a horrible stapled-on mess.
yubblegum 2y ago
> explicit take down of ... "go func" I stopped at "go statements are a form of goto statement." This is simply not correct. They have some diagrams and squinted and said "hey, that looks the same as a goto statement", but unfortunatley they have their diagrams wrong. "go func" will run at scheduler's pleasure, not immediately after the statement "go func..". A goto statement is a deterministic flow control directive. It will goto where you tell it.
- MarkMarine 2y ago
  you should have read the rest of it then, because in the context of Dijkstra's famous paper [0] (that this is written in the style of) the argument here is being able to understand program flow in the programmers' mind. Your description of the go func actually makes it WORSE, because the program doesn't just go there, it goes there later. [0] https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
  - yubblegum 2y ago

bullen 2y ago

Security Manager is one of the only unique selling points of Java, to remove it (without removing it because you need it underneath) is as big of a blunder as removing Applets from browsers and replacing it with something worse: WASM without GC and then adding GC to WASM... If SVTwP is not better than NIO; Java ends with JDK 23. > Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem Because no feature added after 1.8 made sense, so nobody upgraded. They are taking decisions off the wrong data. > they are encouraged to transition to alternative sandboxing and API interception mechanisms Feel free to link to anything useful!

oblio 2y ago
There are plenty of places that are at least on Java 11, so I highly doubt the "no one upgraded" part.
- bullen 2y ago
  I meant to 17 so they would see the warning.
lief79 2y ago
That has as much to do with Oracle lawyers and ambiguous licensing issues as anything else.
atomicnumber3 2y ago
Unique, sure. Selling point? I really don't think so. This idea of "safely" running untrusted code in the jvm sandbox both never materialized (constant stream of sandbox-escape vulns i've seen over the years) and also was at the wrong level - anyone doing multi-tenant code execution is doing it via things like gvisor or at the OS-level. I don't think I buy your assertion that nobody has upgraded. I know of a 3000-4000-strong eng org at a certain company that has upgraded all the way from 8 to 17 as of when i left 3 years ago. They primarily wanted the GC improvements because they translated into huge immediate efficiency gains on their workloads (huge Spark/Hadoop spend savings, and moderate savings for the non-big-data jvm workloads). I do share your lament of applets though. It would've been a way better runtime for portable/install-less/JIT-install things than the current nightmare of html/css/js/etc. But they just didn't have the browser integration - it would've needed to be more than just "look we put a drawing surface into the web browser" - and they didn't have the "window into the world" either (that's browsers). Unfortunately, it's the front door program and platform that owns the users, and that's web browsers.

raducu 2y ago

> No pinning virtual threads is huge Have ALL previous pinning scenarios been resolved, including native calls?

atomicnumber3 2y ago
ALL? no. but based on my read of the article's linked bit on thread pinning, it seems like it has been substantially resolved, and remaining pinning scenarios are quite rare (they mention you can look for them in JFR).
- raducu 2y ago
  I was wondering if native calls were solved, but I don't see how those can ever be solved
  - samus 2y ago
    In the long term native calls will require a command line flag to be permitted. No matter whether they are done via FFI or JNA. By then, libraries better figure out a way to document them or to reduce using them as much as possible. A lot of off-heap memory trickery should now be possible via (unsafe of course) functions from the FFI library.

jsiepkes 2y ago

> I really want structured concurrency out of preview!! I'm guessing they thought it couldn't hurt to do another round of testing. Since OpenJDK 25 will be an LTS release, I suspect it will go out of preview in the next release.

jayd16 2y ago

I'm glad they're working on it but I still can't help but my miss async/await. In C# the API is a bit overturned for sharing a GUI thread but it does the job. Structured Concurrency makes the scopes more obvious but I'm worried about the ergonomics. What is the core use case for the design? Is it just to make collecting a set of concurrent tasks bullet proof? Are we going to see scopes abused and passed around to handle the non-happy path of "a function always ends before it's caller." It doesn't seem to service GUI programming all that well. I guess there's still Kotlin's approach but hopefully something happens on the Java side.

atomicnumber3 2y ago
"Is it just to make collecting a set of concurrent tasks bullet proof?" At a surface level, yeah basically. And ask anyone who's used python's multiprocessing how hard that is to actually get completely right. I don't think structured concurrency is going to be some panacea of multiprocessing at all. It's to address code you'd see in golang that's like, make a waitgroup, fire off N goroutines, wait for success and gather errors. That code is not incredibly fun in Java right now. w.r.t. async/await, imo the beauty of virtual threads is that you've no longer got function coloring, and the "await"s are free, implicit, and performant. and of course you're never precluded from using higher level application locks that have always been there, including synchronized now. Also, specifically w.r.t. gui programming, I think Java is unfortunately kind of stuck. JavaFX has been put into the back of the closet, Swing is completely ossified (though tbh I still like it), and what energy is there behind any non-electron/web GUI development anymore anyway? In a world where vscode, one of the most popular new "IDEs"/IDE platforms, is written in a frickin web browser, and mobile apps dominate a huge % of what constitutes "native" GUI development, I don't really blame Java for not prioritizing it beyond keeping Swing working on e.g. hiDPI displays and so on.

neonsunset 2y ago

> Java streams is that they're as powerful as Ruby's functional-style operation chaining (arr.map{}.reduce(:+) etc) This is not a unique Ruby feature though. Iterators are very common nowadays. Java streams have okay performance, much like .NET's LINQ you likely won't be able to use them in a really performance-sensitive code (although LINQ is improving quite a bit with each new release, overall it performs moderately to significantly faster than Java Streams, but usually slower than Rust iterators).

pjmlp 2y ago

.NET also removed their version of security manager (Code Access Security) for similar reasons. Just like I expect WebAssembly security conversation to change when folks start plugging components left and right, beyond straight compute logic.

msgilligan 2y ago

> I'm inappropriately smug to have been proven right now, several decades later. I think you were proven right at least a decade ago. As you said, this is just the final whimper.

scottlamb 2y ago

> No pinning virtual threads is huge. Finally you can virtual thread with near-wild abandon, as God intended. I see that formerly it pinned virtual threads "when it executes code inside a synchronized block or method", and "frequent pinning for long durations can harm the scalability of an application by capturing carriers". You were supposed to "avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use java.util.concurrent.locks.ReentrantLock instead." How big a problem was this in practice? On the one hand, I think "harm the scalability" is putting it mildly—if you have a whole bunch of virtual threads doing IO, only running num_cores of them at once is devastating. On the other hand, holding a lock while doing IO smells wrong. Is this really common?

mping 2y ago
I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized. If the performance with vthreads was much worse for some cases it would be a bit of failure
- re-thc 2y ago
  > I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized. Those usually have company / community backing that gets it fixed. The irony is you patch the ORM and you patch the JDBC driver only to realize the database pooling library in-between is the 1 that's broken and the author refuses to fix it.
  - samus 2y ago
    Switching `synchronized` for `ReentrantLock` is possible in principle, but it makes the code harder to read and opens the door to subtle concurrency bugs. Library authors really don't want this kind of code churn for an issue that is not their fault, not their responsibility to solve, and that will get a bugfix before long that maybe even qualifies for a backport to LTS 21.
re-thc 2y ago