3 ms·

The old JVMs will still be available and you so will the Docker containers with them. That said the writing has been on the wall since Java 9's project Jigsaw.

The old JVMs will still be available and you so will the Docker containers with them. That said the writing has been on the wall since Java 9's project Jigsaw. If you have a product that depends on it, I'm surprised you were caught unaware. With more control over what is exported, the amount of compiler optimisations possible greatly increases.

quantumwoke 4y ago
Not if the software I depend on requires the latest JVM (which it will).
- geodel 4y 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 4y 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 4y ago
      Then just enable it at start time with a flag.
    - tsimionescu 4y 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 4y 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 4y 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 4y 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 4y 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.

quantumwoke 4y ago

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

geodel 4y 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 4y 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 4y ago
    Then just enable it at start time with a flag.
  - tsimionescu 4y 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 4y 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 4y 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 4y 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 4y 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.