4 ms·

As the maintainer of a large piece of Java software that interacts with legacy code in over 50% of the codebase, this was a very scary read. It sounds like the

As the maintainer of a large piece of Java software that interacts with legacy code in over 50% of the codebase, this was a very scary read. It sounds like the entire basis for my software which tens of thousands of people rely on every day is soon to be "restricted". I cannot prepare my users for the fact that my software _will not work with no recourse_ in the future. I understand the JVM's need for safety, but this is personally destroying my livelihood. It's along the lines of telling Ruby users one day that monkey patching will be phased out in the next release. I suppose the next layer down the chain is to start patching code with ASM. Ugh.

Pet_Ant 3y ago
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 3y ago
  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.
JanecekPetr 3y ago
> "will not work with no recourse" No, the CLI `--add-opens` CLI option will stay. In other words, applications will need to consciously enable the encapsulation-breaking stuff. Is that bad? Modern software moved to public APIs quite a bit ago. That said, if old applications want to use new JDKs, they will require quite some developement, yes.
- bzzzt 3y ago
  One of Java's strong points has always been the amount of care to source and binary compatibility (Java 8 classes work fine on Java 20, source code only need minor modifications). I welcome the new restrictions since they make Java more secure and future-proof, but they have a price. There's lots of (framework) code that makes use of those loopholes and many Java projects already have issues with maintenance since it's not the 'hot stuff' anymore.
amluto 3y ago
It sounds like --add-opens, etc will still exist. Can you use that? It would, as discussed, be an admission of legacy-ness.
blibble 3y ago
the entire low latency sector is will be stuck on java 8 until they figure out what they're going to do with Unsafe which may be forever
- pjmlp 3y ago
  JNI exists.
  - SpaghettiCthulu 3y ago
    JNI is known to be slow
    - pjmlp 3y ago
      Marshaling is slow, the trick is not to have chatty interfaces.
  - blibble 3y ago
    using JNI would turn 1 intrinsic'ed instruction into about 800 which might be an acceptable tradeoff if you're shovelling JSON to a websocket not so good if you're a smart order router trying to hit a level that will be gone in under a microsecond
    - ptx 3y ago
      Won't Project Panama solve this? One of the goals in JEP 424 is to provide performance competitive with sun.misc.Unsafe so that (it says later in the document) it can eventually be removed.

Pet_Ant 3y ago

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 3y ago
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.

JanecekPetr 3y ago

> "will not work with no recourse" No, the CLI `--add-opens` CLI option will stay. In other words, applications will need to consciously enable the encapsulation-breaking stuff. Is that bad? Modern software moved to public APIs quite a bit ago. That said, if old applications want to use new JDKs, they will require quite some developement, yes.

bzzzt 3y ago
One of Java's strong points has always been the amount of care to source and binary compatibility (Java 8 classes work fine on Java 20, source code only need minor modifications). I welcome the new restrictions since they make Java more secure and future-proof, but they have a price. There's lots of (framework) code that makes use of those loopholes and many Java projects already have issues with maintenance since it's not the 'hot stuff' anymore.

amluto 3y ago

It sounds like --add-opens, etc will still exist. Can you use that? It would, as discussed, be an admission of legacy-ness.

blibble 3y ago

the entire low latency sector is will be stuck on java 8 until they figure out what they're going to do with Unsafe which may be forever

pjmlp 3y ago
JNI exists.
- SpaghettiCthulu 3y ago
  JNI is known to be slow
  - pjmlp 3y ago
    Marshaling is slow, the trick is not to have chatty interfaces.
- blibble 3y ago
  using JNI would turn 1 intrinsic'ed instruction into about 800 which might be an acceptable tradeoff if you're shovelling JSON to a websocket not so good if you're a smart order router trying to hit a level that will be gone in under a microsecond
  - ptx 3y ago
    Won't Project Panama solve this? One of the goals in JEP 424 is to provide performance competitive with sun.misc.Unsafe so that (it says later in the document) it can eventually be removed.