4 ms·

This also brings some big gotchas, such as the closing of encapsulation loopholes. Unsafe code and various hacks calling into the JDK will break a lot of progra

by cmckn 5y ago

This also brings some big gotchas, such as the closing of encapsulation loopholes. Unsafe code and various hacks calling into the JDK will break a lot of programs; so you might be stuck on 11 if you use HBase, Spark, etc.

pgwhalen 5y ago
You won’t be stuck, you just need to add some command line flags when running your application, as a way of acknowledging these packages are breaking encapsulation.
- cmckn 5y ago
  “Some” as in dozens (for my apps, at least). It’s a solution, but not a great one. The projects I depend on will have to remove such usages eventually to avoid awful UX (and avoid punching holes in encapsulation).
  - pgwhalen 5y ago
    > The projects I depend on will have to remove such usages eventually to avoid awful UX This seems like exactly the intended effect to me.
  - samus 5y ago
    For server application, this is a one-time administration effort. If you are concerned about `--illegal-access=allow`: yes, you should strive to get rid of it before security auditors blow an artery because of it. Desktop applications are usually not delivered as bare JARs, but with wrapper binaries or scripts, where such flags are supposed to go.
ragnese 5y ago
I must have missed this topic. What are these encapsulation loopholes that are being closed?
- jmiserez 5y ago
  The --illegal-access argument is removed, see JEP 403: https://openjdk.java.net/jeps/403 https://openjdk.java.net/jeps/403