4 ms·

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

by 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
      The Security Manager API hasn't been an important Java security feature for many years. It was a security feature for Applets, and over the past decade it's been used by a few applications mostly for monitoring/toy sandboxing. In any event, a vanishingly small number of applications use it. Strong encapsulation is part of a long-term effort to make Java more secure, as threats are changing. Also, encapsulation isn't a breaking change. Java's strong backward compatibility commitment is with respect to the Java SE specification. No APIs are affected. It's only internal classes that have always been subject to change, and with clear warnings that they must not be accessed, that are encapsulated.
  - josephcsible 5y ago
    Are Python, Ruby, and Lua all inherently insecure? Why do so many programs that care about security use them? They all allow monkey patching, after all.
    - pron 5y ago
      Obviously, Java is used for much more critical applications than Python, Ruby, or Lua, but I don't know enough about their security strategy. Just as Java's performance is constantly being improved, so does its security.
      - josephcsible 5y ago
        What language besides Java has a "feature" that requires a whitelist to use reflection, that you can't just say "everything" for? Or is Java the only secure programming language that exists?
- samus 5y ago
  At any moment, Oracle could change the package names of all internal code from `com.sun` to `com.oracle` or to have a randomized prefix, which would break all those programs as well.
  - josephcsible 5y ago
    They could, sure, but that would again be a breaking change for the sake of being a breaking change. Also, maybe since those "nonportable" things are so widely used, Oracle should just add them to the API officially.
    - pron 5y ago
      Java's backward compatibility applies only to the spec, i.e. the API. If any change to any method in the ~6M MLOC standard library is a "breaking change," then nothing all changes are "breaking changes," and it doesn't matter if there's good reason for them or not; we want things to not break, so internal code needs to be encapsulated. As to the last remaining popular "non-API-APIs", which is mostly just Unsafe, it is, indeed not encapsulated, and over time it will be shrunk only as replacement APIs are available.

by pron 5y ago

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
    The Security Manager API hasn't been an important Java security feature for many years. It was a security feature for Applets, and over the past decade it's been used by a few applications mostly for monitoring/toy sandboxing. In any event, a vanishingly small number of applications use it. Strong encapsulation is part of a long-term effort to make Java more secure, as threats are changing. Also, encapsulation isn't a breaking change. Java's strong backward compatibility commitment is with respect to the Java SE specification. No APIs are affected. It's only internal classes that have always been subject to change, and with clear warnings that they must not be accessed, that are encapsulated.
- josephcsible 5y ago
  Are Python, Ruby, and Lua all inherently insecure? Why do so many programs that care about security use them? They all allow monkey patching, after all.
  - pron 5y ago
    Obviously, Java is used for much more critical applications than Python, Ruby, or Lua, but I don't know enough about their security strategy. Just as Java's performance is constantly being improved, so does its security.
    - josephcsible 5y ago
      What language besides Java has a "feature" that requires a whitelist to use reflection, that you can't just say "everything" for? Or is Java the only secure programming language that exists?
samus 5y ago
At any moment, Oracle could change the package names of all internal code from `com.sun` to `com.oracle` or to have a randomized prefix, which would break all those programs as well.
- josephcsible 5y ago
  They could, sure, but that would again be a breaking change for the sake of being a breaking change. Also, maybe since those "nonportable" things are so widely used, Oracle should just add them to the API officially.
  - pron 5y ago
    Java's backward compatibility applies only to the spec, i.e. the API. If any change to any method in the ~6M MLOC standard library is a "breaking change," then nothing all changes are "breaking changes," and it doesn't matter if there's good reason for them or not; we want things to not break, so internal code needs to be encapsulated. As to the last remaining popular "non-API-APIs", which is mostly just Unsafe, it is, indeed not encapsulated, and over time it will be shrunk only as replacement APIs are available.