Hacker News Reader

Comment by avalys | Hacker News Reader

Fair point, although I think it's true that C++ gives you more rope to hang yourself with, and if I had to choose, I'd rather maintain a crusty old codebase written in Java than one written in C++.

View on HN

The issue is that the JVM has started deprecating features which old codebase rely on.

I don't work with it, but even I know about the JVM no longer supporting sandboxing or being able to kill threads programmatically.

C++ doesn't have this issue because you can still deploy code from an old toolchain onto a modern OS.

You can and always have been able to .destroy() threads in java, but doing so breaks the memory model in ways that make it clear that you should never do it. My guess is that if you're kill heavy in c++, then you've also run into bugs waiting on locks of threads you've now just murdered. That's why there's a ton of great abstractions for how to "kill work running somewhere else" that doesn't leave your application in a potentially unstable state.

Java 9+ sure did kill off a lot of things that weren't particularly ideal. Most normal devs who don't write libraries probably can't even name a single feature removed (corba, script interpreters, some jmx cruft, etc). Most of what was culled still exists in libraries that could easily be added back with project imports. Maybe Java applets are super dead now? I don't believe any modern browsers still support native plugins, but maybe there are some niche individuals bemoaning the loss of java web start.

As for the "can still deploy code" comment, the same applies to java. Look around, and sadly you see very old releases of java still in use today. My guess is that if I fired up a java 1.0 compiler and JVM today, it would run on my PC (poorly).

Before criticising something, please consider being well enough informed to warrant the comment.

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.

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.

Reply on news.ycombinator.com