[snovv_crash]

I want to run untrusted code in the JVM, and limit its access to IO and compute so it can't phone home or mess up my system. This used to work with the Security Manager plus being able to kill threads.

Now, based on the new thread killing implementation, a malicious thread can just catch the exception and keep running, and on top of that the Security Manager is being removed too.

So now my options are, switch to C++ and Lua, or run every sub-component in its own VM and add a bunch of IPC in the middle of my application. Or maybe port it all to JavaScript. Massive headache, performance implications are bad and it breaks continuity in an open source community that's been running since 2001.

This is my use case, maybe hello world 101 doesn't have any problems but I'm sure anyone doing more complex stuff is going to hit the same kind of issues.

[adra]

You do have some options in the JVM world. As mentioned, you should still be able to kill threads if you really wanted to, but if you wanted to pivot to JS/LUA, there are still jsh alternatives like rhino in JVM to avoid some of the larger reworks. They are based on their own stack/continuation work of over a decade ago, so not fresh. You may want to look at virtual thread pools through. Since these are green threads and the JVM preempts them aggressively, there may be the abstractions you're able to exploit for your more aggressive culling needs.

I don't know about security manager though. I haven't poked at it for a while, but I wasn't aware that they removed it? Maybe you just need to opt I to the JVM access rule to support it. You can always layer your security with a separate class loader, which can prevent child tenants from even seeing protected classes and statics, which is always good security layering if untrusted is your problem.