Peter Firmstone has posted "Security Baked Into the JVM: why fork Apache River and OpenJDK?" - a title that does a LOT of work, and it rolls up a lot of observations in a single, innocent question.
What's happening is that he's forked Apache River - the reference implementation of Sun's JINI - into a fork of the JVM. The River fork is called "JGDMS," the JVM fork is called "DirtyChai."
JGDMS is a rebranding for JINI; JINI was a massively horizontally distributed service layer. Rather than dispatch remote services to a specific endpoint, JINI dispatched requests and responses into a grid that was composited by members. It wasn't UDP, necessarily, where you were issuing packets to a group of participants, but it worked like UDP in that any available responder could respond, so you had a potentially massive service network that self-healed.
It was incredibly powerful, but difficult to express cleanly, and Sun's commitment to specification over implementation meant that they described the specs and not how to actually use it. Books on JavaSpaces, the data storage mechanism in JINI, failed to include code that demonstrated starting or connecting to the services. Everything was high concept and relatively little deliverable code: readers were left going, "This looks awesome, can anyone show me how to do it despite my reading a book on how to do it just now?"
This kind of structure implies a heavy reliance on security, too: when every node is potentially a peer, you have to consider some way to validate the peer, or else you're opening your system to remote injection of malicious code.
And Java deep-sixed the SecurityManager, starting deprecation in Java 17 and removing it altogether in Java 24, with no real replacement. The SecurityManager was poorly understood, and rarely used outside of a few circumstances (application servers, OSGi containers and, well, JINI); sure, the primary surface people ran into was applets, and they were gone, but that doesn't mean security should have been discarded.
Getting rid of security in the JVM might make things much easier for everyone involved - but once you open that door, a host of security concerns fly through it, and they're messy and poorly understood and often conflicting. But "difficult" isn't the same as "unneeded," at all: by removing all of the mechanism, a stray bit of code, possibly delivered by an external actor in a world where interoperability is so common and becoming more common-er, can gut an enterprise system and addressing that is far less trivial now than it ever was before.
So Firmstone is doing two things at once: reviving JINI (a peer network service) and reviving security at the JVM level, although he doesn't describe exactly how the security works here, deferring that to a future post that will probably be a must-read. He nods at the mechanism enough to describe it in general without diving in, which is fine, because:
He includes a runnable "Hello World" that actually uses JINI and the security model, fully - provided you run with his specific JVM.
And here we hit the real speed-bump along this happy trail. Few really understand JINI, but that's just education as a barrier; one can imagine writing documentation that actually communicates the concepts effectively for once.
But the requirement for a specific JVM is likely to affect viability rather severely. There's no indication whether DirtyChai has been run against the compatibility kit for Java - without that, it's "compatible with Java" and isn't "Java." But even if it were an actual Java implementation, a peer of Temurin, Azul, Coretto, etc., asking a clientele to have a specific JVM requirement makes the technology a very hard sell for commercial viability.
It's an incredible effort, and a laudable one. With any luck, it'll be influential and maybe Java will see value in security again, without the old SecurityManager oddities that prevented so many from using it.
But for right now: it's more interesting than relevant, unfortunately, almost like a post-mortem for JINI while it's still trying to breathe.