3 ms·

Not if the software I depend on requires the latest JVM (which it will).

geodel 3y ago
Well new JVM rules comes with new JVM. So something gotta give. Leaving Java be potentially unsafe just because few customer relied on it would be irresponsible behavior on JDK maintainers part.
- exabrial 3y ago
  I'm not sure how current JVMs are "unsafe" though. If you go messing with the internals of third party classes, seems like any consequences should be obvious.
  - kaba0 3y ago
    Then just enable it at start time with a flag.
  - tsimionescu 3y ago
    > If you go messing with the internals of third party classes, seems like any consequences should be obvious. The point made in the article is that it's often third-party libraries that do this, breaking invariants in your code. And, with older JVMs, it won't be immediately obvious to you as a user of that library that this is happening.
    - exabrial 3y ago
      I can't recall a time when 3rd party code has changed something in my code and broke it. I was hoping someone could provide me with an example
      - tsimionescu 3y ago
        Try loading a library that uses com.sun.* through reflection in a program running on JVM 9 or higher with default settings and you'll see an example. Maybe it hasn't happened to code that you personally wrote, but it has certainly happened this way to code that someone at OpenJDK wrote.
      - kaba0 3y ago
        But that third party code may depend on some JVM internal through unsafe, which latter might change (and one really should not depend on internals) and break your code.
Pet_Ant 3y ago
Well they have you covered: > To balance the need for integrity with both the circumstantial, convenience uses of JDK internals and the essential uses, Java gives the user – the application's owner (typically its author, maintainer, or deployer) – the final say on which strong encapsulation boundaries are in place and which should be ignored. This freedom is offered under the guiding principle that the ability of one component to encroach on the boundaries of another must be explicitly granted by the application. Libraries cannot choose to obtain encapsulation-busting "superpowers" without the knowledge and consent of the application's owner.

Well new JVM rules comes with new JVM. So something gotta give. Leaving Java be potentially unsafe just because few customer relied on it would be irresponsible behavior on JDK maintainers part.

exabrial 3y ago
I'm not sure how current JVMs are "unsafe" though. If you go messing with the internals of third party classes, seems like any consequences should be obvious.
- kaba0 3y ago
  Then just enable it at start time with a flag.
- tsimionescu 3y ago
  > If you go messing with the internals of third party classes, seems like any consequences should be obvious. The point made in the article is that it's often third-party libraries that do this, breaking invariants in your code. And, with older JVMs, it won't be immediately obvious to you as a user of that library that this is happening.
  - exabrial 3y ago
    I can't recall a time when 3rd party code has changed something in my code and broke it. I was hoping someone could provide me with an example
    - tsimionescu 3y ago
      Try loading a library that uses com.sun.* through reflection in a program running on JVM 9 or higher with default settings and you'll see an example. Maybe it hasn't happened to code that you personally wrote, but it has certainly happened this way to code that someone at OpenJDK wrote.
    - kaba0 3y ago
      But that third party code may depend on some JVM internal through unsafe, which latter might change (and one really should not depend on internals) and break your code.

Pet_Ant 3y ago

Well they have you covered: > To balance the need for integrity with both the circumstantial, convenience uses of JDK internals and the essential uses, Java gives the user – the application's owner (typically its author, maintainer, or deployer) – the final say on which strong encapsulation boundaries are in place and which should be ignored. This freedom is offered under the guiding principle that the ability of one component to encroach on the boundaries of another must be explicitly granted by the application. Libraries cannot choose to obtain encapsulation-busting "superpowers" without the knowledge and consent of the application's owner.