> This discussion is about a game client, not the server. Well, I didn't know that's what this discussion is about, but sure, we can talk about that. :) > A r

> This discussion is about a game client, not the server. Well, I didn't know that's what this discussion is about, but sure, we can talk about that. :) > A replacement solution would have to work everywhere Java runs, and should not impact the user's system in any noticeable way. Except 1. there's little demand for such a system in the JDK (and, as I've said, you can do something reasonable on your own with modules, class loaders, and a tiny bit of instrumentation) and 2. I don't think anyone offers such a general mechanism, especially as different programs would have different requirements on robustness, some of which cannot be achieved in-process (e.g. web browsers, the prime example of a program running untrusted code, these days use process isolation). > The docs, at the time, implied SecurityManager was the way to go to run untrusted code, similar to Applets. Yes, that was the best way; whether or not the best was good enough is another matter. > Since there is no reasonable alternative and the JDK team has seemingly given up on this feature we've instead opted to require all plugins to be source-available, manually vet the code, and build & distribute via our CI & only allow the client to load plugins signed by our CI. I would say that even SM may not have given you what you need, but yeah with it or without it, some other approaches are required for better fortification. I would recommend additionally looking into some sort of basic sandboxing -- which will control which APIs are exposed to the plugin -- using modules and instrumentation (that can inspect/restrict some operations that are exported by, say, the java.base module).