5 ms·

I see why the SDK and standard library maintainers would want this change but as an application level programmer I wouldn't want this change. They mention "the

I see why the SDK and standard library maintainers would want this change but as an application level programmer I wouldn't want this change. They mention "the impending removal of the Security Manager (JEP 411), we need strong encapsulation to support the creation of robust security layers protected from interference by other code". That should actually be a negative point against this JEP. The security manager was removed as no one used it well or found it useful. Every on e of these features were added because they were useful to java developers. The move to modules and Unsafe have been enough pain for recent times.

vips7L 2y ago
As an application developer I love these changes. I do not want some library calling out to architecture specific binaries without me knowing. I want to have to enable that for them so I know that my application is portable. I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written.
- cempaka 2y ago
  And I don't want the JVM hamstrung from a whole host of optimizations because this random stuff could be happening at any point.
  - LegionMammal978 2y ago
    Any general-purpose JVM is already going to have JNI entry points which bypass privacy. They can certainly restrict JNI as a whole and make users jump through hoops to enable it, but they're not going to be tearing it out for a long, long time.
- mdaniel 2y ago
  > I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written. You have a very strange threat model given how stunningly trivial it is to decompile .class files I'm with you on the JNI but I am not willing to "baby with the bathwater" the Reflection API just avoid having to check the bytecode for Runtime.loadLibrary
  - thfuran 2y ago
    How is decompiling the bytecode relevant? The issue isn't hiding secrets in the code, it's the application breaking at runtime due to violating invariants or assumptions.
    - mdaniel 2y ago
      private java.security.PrivateKey _key; $ java -jar cfr.jar ... $ sed -i"" -e s/private/public/g $(find . -name "*.java") $ javac ... and now Reflection doesn't need setAccessible and your threat model of "but my field is private!!11" has gone poof
      - vips7L 2y ago
        Awesome, you now have a private fork! You the application developer now know your code isn't portable with the library! The JVM also can do its optimizations without having integrity change from under its feet at runtime! Win win!
        mdaniel 2y ago
        Ok, I hear you, so let's mandate that every class have a .gpg signature to really double down on integrity. The JVM should have to have every gpg public key registered as a Trusted Platform Module Author. Win win on how sekure everything will be, and I can always resign every class with my .gpg signature. That really sounds like a win for the day-to-day Java developer, doesn't it? I'm sure that would never cause weird errors in day to day work just to address some niche audience who is really, really into chain of trust The point I'm making is that I don't understand for the life of me whose problem this egregiously disruptive change is solving outside of the NSA, who I'm sure have their own JVM builds and can leave the rest of us out of it
        vips7L 2y ago
        Again I think you have a deep misunderstanding of how this works. This puts control into the hands of the everyday application developer! It ensures that the application developer knows what correctness, portability, and integrity guarantees their program has.
- dxxvi 2y ago
  Do you think you're like Apple: not allowing people to fix their phones, laptops ...?
  - Pet_Ant 2y ago
    I don’t want the community hijacking my library by fossilizing some implementation detail. If you want to fork it, own it and do it, but don’t force that on me by using something you weren’t meant to and then bitch and moan when I break your code by changing some detail.
    - zdragnar 2y ago
      You can make that argument either way. People will always complain about the decisions you make and the ones you don't. The semantics of encapsulation are sufficient. Anyone who breaks them knows it's on them, and if they don't, they certainly should have. It's not worth sweating all the maybes and what-ifs.
      - vips7L 2y ago
        > Anyone who breaks them knows it's on them, and if they don't, they certainly should have. I agree, the issue arises when library developers make this decision and application developers have to deal with the fall out of that. Application developers need to know when things like this happen.
        zdragnar 2y ago
        So use an older version of the library, or stop using the library, or work around it. Libraries with such bad behavior are going to be infrequently used, or abandoned quickly regardless.
  - vips7L 2y ago
    I don't see how this is relevant. This purely puts control into the hands of application developers. It lets them know exactly what correctness, portability, and integrity guarantees their application has. The application developer STILL can "fix their phone", but they have to enable it at the command line. It pevents library developers from making decisions for application developers without them knowing.
mdaniel 2y ago
I agree with you, and think a perfectly reasonable middle ground would be the same way they allowed the SecurityManager in the first place: if you have such rampantly strict integrity requirements, launch the JVM with -Djava.security.manager (or I guess in this case -Djava.security.integrity) and your JVM will run in lockdown mode I do see the "by default" in the title, but while I would be turbo sad I would also gladly accept -Djava.security.integrity=false to allow me to opt out of this DRM-esque stuff And I say DRM but I could also imagine a world in which this stunt would be the death knell to Spring :-(
- remexre 2y ago
  How is this DRM-like? It seems to me that this is putting control in the hands of the application developer instead of the library developer, not moving it to Oracle or anyone else...
  - mdaniel 2y ago
    I consider any action in which the JVM thinks it knows better than me what I can and can't do to running code to be a restriction of my rights. The number of bugs I have fixed, worked around, or triaged using the Reflection API vastly outnumbers the big fat zero of times where someone has complained about an integrity violation on the JVM So, like I said: if you're a big HFT fund and you need your JVM to do crazy integrity assertions, good for you, but don't burn the whole world down for them. Hell, I would be Azul makes a killing catering to that audience, so let them sell an integrity enabled JVM and leave the rest of us out of this fight
    - vips7L 2y ago
      It seems like you have a misunderstanding of how this works. If you want or NEED to do the things that break integrity you still can do them. You just need to enable them at the command line and admit that "yes I know these things break integrity and that I may not get the best performance or may face crazy bugs from unsafe apis or non-portable code".
    - pron 2y ago
cbsmith 2y ago
> The security manager was removed as no one used it well or found it useful. That's as much an indictment of the Security Manager than anything else. ;-) > Every one of these features were added because they were useful to java developers. Which creates a requirement in my mind that removing those features needs to be justified by adding more benefit than they take out, but it is entirely possible that those features were the best way to address the needs of Java developers. The reality is that Java is no longer seen has being a high integrity runtime anymore, so nobody uses it that way. The use cases for a high integrity runtime haven't gone away though.
pron 2y ago
First of all, what's been a pain wasn't modules (their encapsulation wasn't turned on until JDK 16; all JDKs before that had the exact same runtime access permissions as JDK 8), but rather the lack of strong encapsulation which led to many libraries simply being non-portable, which then made the applications using them non-portable without their knowledge. People only thought modules were the cause because modules landed in JDK 9 and were the most famous feature in that release (even though their runtime encapsulation wasn't turned on until JDK 16), and JDK 9 happened to be one of the biggest releases ever, which changed many internals that libraries had hacked into. If virtual threads had landed in JDK 9 rather than modules, the result would have been similar. The only reason you didn't see a lot of breakages due to virtual threads is that they were introduced after strong encapsulation. Second, the point about SecurityManager is a subtle one. SecurityManager was a complex security mechanism; this isn't. However, because integrity is a prerequisite to robust security, SM had to allow configuring integrity, but it was extremely hard to configure correctly. Now it's on by default. If you have any sort of authentication/authorisation mechanism in your application (nothing to do with SecurityManager), then an accidental mistake in any dependency or transitive dependency may result in a vulnerability that would allow a remote attacker to bypass your security mechanism, because the attack surface area is the entire program. Finally, the lack of integrity meant that some powerful performance optimisations can't be performed. Even simple constant-folding of Strings or final fields cannot be done because any library could unilaterally choose to mutate a String or a final.

vips7L 2y ago

As an application developer I love these changes. I do not want some library calling out to architecture specific binaries without me knowing. I want to have to enable that for them so I know that my application is portable. I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written.

cempaka 2y ago
And I don't want the JVM hamstrung from a whole host of optimizations because this random stuff could be happening at any point.
- LegionMammal978 2y ago
  Any general-purpose JVM is already going to have JNI entry points which bypass privacy. They can certainly restrict JNI as a whole and make users jump through hoops to enable it, but they're not going to be tearing it out for a long, long time.
mdaniel 2y ago
> I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written. You have a very strange threat model given how stunningly trivial it is to decompile .class files I'm with you on the JNI but I am not willing to "baby with the bathwater" the Reflection API just avoid having to check the bytecode for Runtime.loadLibrary
- thfuran 2y ago
  How is decompiling the bytecode relevant? The issue isn't hiding secrets in the code, it's the application breaking at runtime due to violating invariants or assumptions.
  - mdaniel 2y ago
    private java.security.PrivateKey _key; $ java -jar cfr.jar ... $ sed -i"" -e s/private/public/g $(find . -name "*.java") $ javac ... and now Reflection doesn't need setAccessible and your threat model of "but my field is private!!11" has gone poof
    - vips7L 2y ago
      Awesome, you now have a private fork! You the application developer now know your code isn't portable with the library! The JVM also can do its optimizations without having integrity change from under its feet at runtime! Win win!
      - mdaniel 2y ago
        Ok, I hear you, so let's mandate that every class have a .gpg signature to really double down on integrity. The JVM should have to have every gpg public key registered as a Trusted Platform Module Author. Win win on how sekure everything will be, and I can always resign every class with my .gpg signature. That really sounds like a win for the day-to-day Java developer, doesn't it? I'm sure that would never cause weird errors in day to day work just to address some niche audience who is really, really into chain of trust The point I'm making is that I don't understand for the life of me whose problem this egregiously disruptive change is solving outside of the NSA, who I'm sure have their own JVM builds and can leave the rest of us out of it
        vips7L 2y ago
        Again I think you have a deep misunderstanding of how this works. This puts control into the hands of the everyday application developer! It ensures that the application developer knows what correctness, portability, and integrity guarantees their program has.
dxxvi 2y ago
Do you think you're like Apple: not allowing people to fix their phones, laptops ...?
- Pet_Ant 2y ago
  I don’t want the community hijacking my library by fossilizing some implementation detail. If you want to fork it, own it and do it, but don’t force that on me by using something you weren’t meant to and then bitch and moan when I break your code by changing some detail.
  - zdragnar 2y ago
    You can make that argument either way. People will always complain about the decisions you make and the ones you don't. The semantics of encapsulation are sufficient. Anyone who breaks them knows it's on them, and if they don't, they certainly should have. It's not worth sweating all the maybes and what-ifs.
    - vips7L 2y ago
      > Anyone who breaks them knows it's on them, and if they don't, they certainly should have. I agree, the issue arises when library developers make this decision and application developers have to deal with the fall out of that. Application developers need to know when things like this happen.
      - zdragnar 2y ago
        So use an older version of the library, or stop using the library, or work around it. Libraries with such bad behavior are going to be infrequently used, or abandoned quickly regardless.
- vips7L 2y ago
  I don't see how this is relevant. This purely puts control into the hands of application developers. It lets them know exactly what correctness, portability, and integrity guarantees their application has. The application developer STILL can "fix their phone", but they have to enable it at the command line. It pevents library developers from making decisions for application developers without them knowing.

mdaniel 2y ago

I agree with you, and think a perfectly reasonable middle ground would be the same way they allowed the SecurityManager in the first place: if you have such rampantly strict integrity requirements, launch the JVM with -Djava.security.manager (or I guess in this case -Djava.security.integrity) and your JVM will run in lockdown mode I do see the "by default" in the title, but while I would be turbo sad I would also gladly accept -Djava.security.integrity=false to allow me to opt out of this DRM-esque stuff And I say DRM but I could also imagine a world in which this stunt would be the death knell to Spring :-(

remexre 2y ago
How is this DRM-like? It seems to me that this is putting control in the hands of the application developer instead of the library developer, not moving it to Oracle or anyone else...
- mdaniel 2y ago
  I consider any action in which the JVM thinks it knows better than me what I can and can't do to running code to be a restriction of my rights. The number of bugs I have fixed, worked around, or triaged using the Reflection API vastly outnumbers the big fat zero of times where someone has complained about an integrity violation on the JVM So, like I said: if you're a big HFT fund and you need your JVM to do crazy integrity assertions, good for you, but don't burn the whole world down for them. Hell, I would be Azul makes a killing catering to that audience, so let them sell an integrity enabled JVM and leave the rest of us out of this fight
  - vips7L 2y ago
    It seems like you have a misunderstanding of how this works. If you want or NEED to do the things that break integrity you still can do them. You just need to enable them at the command line and admit that "yes I know these things break integrity and that I may not get the best performance or may face crazy bugs from unsafe apis or non-portable code".
  - pron 2y ago

cbsmith 2y ago

> The security manager was removed as no one used it well or found it useful. That's as much an indictment of the Security Manager than anything else. ;-) > Every one of these features were added because they were useful to java developers. Which creates a requirement in my mind that removing those features needs to be justified by adding more benefit than they take out, but it is entirely possible that those features were the best way to address the needs of Java developers. The reality is that Java is no longer seen has being a high integrity runtime anymore, so nobody uses it that way. The use cases for a high integrity runtime haven't gone away though.

pron 2y ago

First of all, what's been a pain wasn't modules (their encapsulation wasn't turned on until JDK 16; all JDKs before that had the exact same runtime access permissions as JDK 8), but rather the lack of strong encapsulation which led to many libraries simply being non-portable, which then made the applications using them non-portable without their knowledge. People only thought modules were the cause because modules landed in JDK 9 and were the most famous feature in that release (even though their runtime encapsulation wasn't turned on until JDK 16), and JDK 9 happened to be one of the biggest releases ever, which changed many internals that libraries had hacked into. If virtual threads had landed in JDK 9 rather than modules, the result would have been similar. The only reason you didn't see a lot of breakages due to virtual threads is that they were introduced after strong encapsulation. Second, the point about SecurityManager is a subtle one. SecurityManager was a complex security mechanism; this isn't. However, because integrity is a prerequisite to robust security, SM had to allow configuring integrity, but it was extremely hard to configure correctly. Now it's on by default. If you have any sort of authentication/authorisation mechanism in your application (nothing to do with SecurityManager), then an accidental mistake in any dependency or transitive dependency may result in a vulnerability that would allow a remote attacker to bypass your security mechanism, because the attack surface area is the entire program. Finally, the lack of integrity meant that some powerful performance optimisations can't be performed. Even simple constant-folding of Strings or final fields cannot be done because any library could unilaterally choose to mutate a String or a final.