3 ms·

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 O

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
  The choice here is not given to the JDK but to the application developer who can choose which protections to turn off in the application's configuration. All it does is prevent libraries doing things that may interfere with the application or impose risks on it without the application knowing about it. > the big fat zero of times where someone has complained about an integrity violation on the JVM ~99% of the migration difficulties from 8 to 9+ were due to integrity violations of the core library (remember, module encapsulation was turned off by default until JDK 16). The cost of that alone is, well, high, and that doesn't even count library vulnerabilities. Integrity violations have been the #1 cause of complaints over the last several years. Integrity is important because it is a prerequisite to portability ("upgradability"), security, correctness, and some important performance optimisations. If you haven't heard people complain a lot about any of these things then you haven't been listening.

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
The choice here is not given to the JDK but to the application developer who can choose which protections to turn off in the application's configuration. All it does is prevent libraries doing things that may interfere with the application or impose risks on it without the application knowing about it. > the big fat zero of times where someone has complained about an integrity violation on the JVM ~99% of the migration difficulties from 8 to 9+ were due to integrity violations of the core library (remember, module encapsulation was turned off by default until JDK 16). The cost of that alone is, well, high, and that doesn't even count library vulnerabilities. Integrity violations have been the #1 cause of complaints over the last several years. Integrity is important because it is a prerequisite to portability ("upgradability"), security, correctness, and some important performance optimisations. If you haven't heard people complain a lot about any of these things then you haven't been listening.