5 ms·

Never seen anyone ask for you to get rid of security manager. Fix and improve it, sure. But no, it had to go and we did not get a suitable replacement. RIP.

pron 2y ago
Of course you did -- many, many, many times -- you just didn't know that that's what you were seeing. People rarely directly asks for an old feature that they're not using to be removed. Rather, they ask for new features that the old feature interferes with. SecurityManager imposed a significant tax on nearly every new feature, as it interacts with just about everything, slowing down much of the work on the JDK. SecurityManager was (actually, still is as it has not been removed yet) simultaneously one of the most expensive features and least used features in the JDK. Everyone who asked for new significant features effectively asked for SM to be removed, as they could not be delivered -- certainly not as expeditiously -- with it in place. In fact, as early as JDK 8, new features (such as streams) had to work around SM (simply documenting that it could not be effectively used in combination with the new feature; few people noticed because few people used SM). With time, it became ridiculous to say that SM is ineffective when used in combination with more and more new features (e.g. virtual threads, and the same would have been the case for Leyden [1]), and it still kept exacting a tax on most uses, so it had to be removed if we were to give people the features they were asking for. The fact that more robust, effective, and relevant security mechanisms are now not only available but have grown far more popular in Java applications than SM ever was only meant that the whatever arguments there may have been to keep it and delay and significantly complicate new features were weak. [1]: I shudder to think how Leyden could be done while keeping SM in some functional state.
- beeboobaa3 2y ago
  > The fact that more robust, effective, and relevant security mechanisms are now not only available but have grown far more popular in Java applications Like what? Or are you referring to isolating the entire JVM? That's pointless for plugin systems that don't want to deal with the ridiculous amount of overhead that'd entail. > SecurityManager was (actually, still is as it has not been removed yet) simultaneously one of the most expensive features and least used features in the JDK Well, yeah. It was hard to implement, I'd know because I was working on integrating it in a plugin framework I was working on at the time. But we eventually abandoned that idea when we heard the announcement of SM being deprecated with no replacement. Would've been great to be able to support sandboxed plugins for the game we were working on.
  - pjmlp 2y ago
    Success of VSCode plugins, microservices, containers, and out of process VSTs, have proven that on modern hardware people favour stability and improved security, over the in process plugins. .NET also dropped their version of SecurityManager when they did the Core rewrite.
    - beeboobaa3 2y ago
      All of those plugins have shit latency. This model is not suitable for games, at all. The plugins need to be able to render their own graphics, which happens at 60~120fps. Also have you ever tried running ~200 JVMs on the same machine?
      - pjmlp 2y ago
        Which games are you shipping in Java that depend on Security Manager's existence? Most games are deployed as services nowadays, they have a full network between their rendering and game logic. Yes, that is what Cloud Services do all the time across the globe in Kubernetes.
        beeboobaa3 2y ago
        > Which games are you shipping in Java that depend on Security Manager's existence? None, because it didn't pan out like I described above. No sense continuing developing something using a technology that is due to be removed. The project was abandoned. This was for a third-party Old School RuneScape client which supports client side Java plugins. The current approach is to manually vet each plugin and its update before it is made available for users to install. > Most games are deployed as services nowadays, they have a full network between their rendering and game logic. Networked games do not communicate at 60~120fps. That's just not how it works, writing efficient netcode with client-side prediction is important for a reason. > Yes, that is what Cloud Services do all the time across the globe in Kubernetes. Yeah, on the servers they pay several grand a month for. Not on end user craptops which is where games obviously run.
      - 2y ago

pron 2y ago

Of course you did -- many, many, many times -- you just didn't know that that's what you were seeing. People rarely directly asks for an old feature that they're not using to be removed. Rather, they ask for new features that the old feature interferes with. SecurityManager imposed a significant tax on nearly every new feature, as it interacts with just about everything, slowing down much of the work on the JDK. SecurityManager was (actually, still is as it has not been removed yet) simultaneously one of the most expensive features and least used features in the JDK. Everyone who asked for new significant features effectively asked for SM to be removed, as they could not be delivered -- certainly not as expeditiously -- with it in place. In fact, as early as JDK 8, new features (such as streams) had to work around SM (simply documenting that it could not be effectively used in combination with the new feature; few people noticed because few people used SM). With time, it became ridiculous to say that SM is ineffective when used in combination with more and more new features (e.g. virtual threads, and the same would have been the case for Leyden [1]), and it still kept exacting a tax on most uses, so it had to be removed if we were to give people the features they were asking for. The fact that more robust, effective, and relevant security mechanisms are now not only available but have grown far more popular in Java applications than SM ever was only meant that the whatever arguments there may have been to keep it and delay and significantly complicate new features were weak. [1]: I shudder to think how Leyden could be done while keeping SM in some functional state.

beeboobaa3 2y ago
> The fact that more robust, effective, and relevant security mechanisms are now not only available but have grown far more popular in Java applications Like what? Or are you referring to isolating the entire JVM? That's pointless for plugin systems that don't want to deal with the ridiculous amount of overhead that'd entail. > SecurityManager was (actually, still is as it has not been removed yet) simultaneously one of the most expensive features and least used features in the JDK Well, yeah. It was hard to implement, I'd know because I was working on integrating it in a plugin framework I was working on at the time. But we eventually abandoned that idea when we heard the announcement of SM being deprecated with no replacement. Would've been great to be able to support sandboxed plugins for the game we were working on.
- pjmlp 2y ago
  Success of VSCode plugins, microservices, containers, and out of process VSTs, have proven that on modern hardware people favour stability and improved security, over the in process plugins. .NET also dropped their version of SecurityManager when they did the Core rewrite.
  - beeboobaa3 2y ago
    All of those plugins have shit latency. This model is not suitable for games, at all. The plugins need to be able to render their own graphics, which happens at 60~120fps. Also have you ever tried running ~200 JVMs on the same machine?
    - pjmlp 2y ago
      Which games are you shipping in Java that depend on Security Manager's existence? Most games are deployed as services nowadays, they have a full network between their rendering and game logic. Yes, that is what Cloud Services do all the time across the globe in Kubernetes.
      - beeboobaa3 2y ago
        > Which games are you shipping in Java that depend on Security Manager's existence? None, because it didn't pan out like I described above. No sense continuing developing something using a technology that is due to be removed. The project was abandoned. This was for a third-party Old School RuneScape client which supports client side Java plugins. The current approach is to manually vet each plugin and its update before it is made available for users to install. > Most games are deployed as services nowadays, they have a full network between their rendering and game logic. Networked games do not communicate at 60~120fps. That's just not how it works, writing efficient netcode with client-side prediction is important for a reason. > Yes, that is what Cloud Services do all the time across the globe in Kubernetes. Yeah, on the servers they pay several grand a month for. Not on end user craptops which is where games obviously run.
    - 2y ago