6 ms·

add-opens was only required starting in 17, and modules, whose encapsulation wasn't even on by default until JDK 16, had little if anything to do with the migra

by pron 5y ago

add-opens was only required starting in 17, and modules, whose encapsulation wasn't even on by default until JDK 16, had little if anything to do with the migration issues from 8 to 9. They just happened to be 9's most famous feature, so they got the blame. Nearly all migration issues were due to libraries bypassing the Java spec in 8 and relying on internal implementation details, essentially becoming intentionally non-portable. Some of them had a good reason to do so, but nevertheless, that's what happened. Java 9 was one of the biggest Java releases ever, internal implementation details changed all over the JDK, so many libraries that had become tied to 8 broke. Now upgrading is no longer too big a deal because all popular libraries have long been fixed. Modules, however, are related to those issues in that now when their encapsulation has finally been turned on (in 16 and 17), they will do their job of preventing this problem of bypassing the spec from recurring (the application is able to grant internal access to a library, but at least it knows there might be a potential maintenance and/or security issue to keep an eye on when it does).

josephcsible 5y ago
My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. > they will do their job of preventing this problem of bypassing the spec from recurring This feels like curing cancer by killing the patient.
- pron 5y ago
  > My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. add-opens, which, again, has been required only since JDK 17, is absolutely essential for Java's security (it is impossible for any Java code to make any strong guarantees without it), and to prevent the kind of problems we've seen when migrating from 8 to 9. The only thing it breaks is the ability to write non-portable libraries without the application knowing about it. There is not a single line of code that would be affected by it that wouldn't have also been susceptible to any change in internal details, which can happen in any release without warning. Since the rate of internal implementation details is only going to grow with the growing investment in Java, this change helps warn against potential issues due to non-portable code. > This feels like curing cancer by killing the patient. JDK 17 adoption is pretty impressive (and faster than 11's). Doesn't seem like the patient is dead.
  - josephcsible 5y ago
    > add-opens [...] is absolutely essential for Java's security (it is impossible for any Java code to make any strong guarantees without it How do you figure? What kinds of guarantees? > to prevent the kind of problems we've seen when migrating from 8 to 9 But it only prevented it from happening later by making it happen now! There's a good chance that most of the programs broken by modules would never have broken otherwise.
    - pron 5y ago
      > How do you figure? What kinds of guarantees? Any, but specifically around security (almost all security is provided by certain preconditions being met, namely that method foo() is called only immediately after ensuring that method bar() returns true, or that an object of type Baz is always initialised in a certain way. Prior to modules, the meaning of any line of Java code anywhere -- including in the JDK itself -- was subject to change by any other line of code in any loaded library through various kinds of monkey patching. You could not guarantee anything. With modules, if `foo` is private, and the only call to it is in `if (bar()) foo();` you can guarantee that foo is only called when bar is true. Now, strong encapsulation isn't airtight yet, and there are still some loopholes left to let straggler libraries catch up or because there aren't replacements to some unsafe operations yet, but it will be very soon. > There's a good chance that most of the programs broken by modules would never have broken otherwise. First, almost all problems migrating to 9+ were because of such non-portable code, and the disruption was quite significant, and the rate of internal change is increasing. Second, this makes it happen now instead of happening, perhaps on a smaller scale, at each and every release for the next decades.
      - josefx 5y ago
        > Any, but specifically around security Ah, so they had to add it because they plan on removing the security manager API. So it is a breaking change for the sake of another breaking change.
        pron 5y ago
unscaled 5y ago
I migrated personally (or overseen migration) of many projects from Java 8 (and even Java 6) to Java 11. Modules in Java 9 were a bit controversial back then, so I guess that's the reason we hear a lot about it, but I haven't encountered an issue related to modules even once. Most of the migration work that was needed was just upgrading libraries, or adding new dependencies for Java EE APIs that moved out of the JDK. And why libraries were incompatible? Relying on undocumented internals is one thing, but the funny thing is that a surprisingly large number of libraries broke because they relied on the format of the Java version string. When it changed from 1.8 to 9.0, they suddenly saw a "Java Version 0" and didn't know what to do with it.
- pron 5y ago
  > When it changed from 1.8 to 9.0, they suddenly saw a "Java Version 0" and didn't know what to do with it. That's true. That change was probably the biggest single "breaking change" in that release.

by pron 5y ago

josephcsible 5y ago

My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. > they will do their job of preventing this problem of bypassing the spec from recurring This feels like curing cancer by killing the patient.

pron 5y ago
> My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. add-opens, which, again, has been required only since JDK 17, is absolutely essential for Java's security (it is impossible for any Java code to make any strong guarantees without it), and to prevent the kind of problems we've seen when migrating from 8 to 9. The only thing it breaks is the ability to write non-portable libraries without the application knowing about it. There is not a single line of code that would be affected by it that wouldn't have also been susceptible to any change in internal details, which can happen in any release without warning. Since the rate of internal implementation details is only going to grow with the growing investment in Java, this change helps warn against potential issues due to non-portable code. > This feels like curing cancer by killing the patient. JDK 17 adoption is pretty impressive (and faster than 11's). Doesn't seem like the patient is dead.
- josephcsible 5y ago
  > add-opens [...] is absolutely essential for Java's security (it is impossible for any Java code to make any strong guarantees without it How do you figure? What kinds of guarantees? > to prevent the kind of problems we've seen when migrating from 8 to 9 But it only prevented it from happening later by making it happen now! There's a good chance that most of the programs broken by modules would never have broken otherwise.
  - pron 5y ago
    > How do you figure? What kinds of guarantees? Any, but specifically around security (almost all security is provided by certain preconditions being met, namely that method foo() is called only immediately after ensuring that method bar() returns true, or that an object of type Baz is always initialised in a certain way. Prior to modules, the meaning of any line of Java code anywhere -- including in the JDK itself -- was subject to change by any other line of code in any loaded library through various kinds of monkey patching. You could not guarantee anything. With modules, if `foo` is private, and the only call to it is in `if (bar()) foo();` you can guarantee that foo is only called when bar is true. Now, strong encapsulation isn't airtight yet, and there are still some loopholes left to let straggler libraries catch up or because there aren't replacements to some unsafe operations yet, but it will be very soon. > There's a good chance that most of the programs broken by modules would never have broken otherwise. First, almost all problems migrating to 9+ were because of such non-portable code, and the disruption was quite significant, and the rate of internal change is increasing. Second, this makes it happen now instead of happening, perhaps on a smaller scale, at each and every release for the next decades.
    - josefx 5y ago
      > Any, but specifically around security Ah, so they had to add it because they plan on removing the security manager API. So it is a breaking change for the sake of another breaking change.
      - pron 5y ago

unscaled 5y ago

I migrated personally (or overseen migration) of many projects from Java 8 (and even Java 6) to Java 11. Modules in Java 9 were a bit controversial back then, so I guess that's the reason we hear a lot about it, but I haven't encountered an issue related to modules even once. Most of the migration work that was needed was just upgrading libraries, or adding new dependencies for Java EE APIs that moved out of the JDK. And why libraries were incompatible? Relying on undocumented internals is one thing, but the funny thing is that a surprisingly large number of libraries broke because they relied on the format of the Java version string. When it changed from 1.8 to 9.0, they suddenly saw a "Java Version 0" and didn't know what to do with it.

pron 5y ago
> When it changed from 1.8 to 9.0, they suddenly saw a "Java Version 0" and didn't know what to do with it. That's true. That change was probably the biggest single "breaking change" in that release.