Hacker News Reader

Comment by mdaniel | Hacker News Reader

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 :-(

View on HN

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...

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

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".

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.

Reply on news.ycombinator.com