Why fork Apache River and OpenJDK for JVM security?

The key question is what isolation the custom JVM actually provides. If the goal is to run code from remote services inside the same process, the project needs a credible enforcement mechanism and a clear account of what that code can access.

Forking River and the JDK might let the project change both the distributed programming model and the runtime rules that support it. But a fork alone doesn't demonstrate that the resulting boundary is secure. The threat model and implementation details matter.

My default would be simpler: don't execute untrusted remote code in the same JVM. Put it behind a separate process and use a defined interface to communicate. That still leaves security work to do, but it avoids depending on an in-process sandbox for that boundary.

There is more to the River lineage than remote method calls. The JavaSpaces model, for example, is a distinct way to coordinate through shared objects. Someone who wants to preserve or develop that style of distributed system might see value in a fork beyond just securing remote execution.

That explains a possible motivation, not whether a particular fork needs its own JDK or succeeds at making the model secure.

I can see why the combination of an older distributed Java model and a custom JDK raises eyebrows. That's a lot of infrastructure to adopt and maintain. Still, comparing it directly with EJB2 can obscure differences in how the systems approach distributed services. I'd want to evaluate the actual programming and security model before treating them as interchangeable.