In Java 17 how do I avoid resorting to --add-opens?

Viewed 7519

As of Java 17 --illegal-access is effectively obsolete https://openjdk.java.net/jeps/403

Any use of this option, whether with permit, warn, debug, or deny, will have no effect other than to issue a warning message. We expect to remove the --illegal-access option entirely in a future release.

Because of this, using openjdk17 early access builds, I'm seeing an issue with jackson https://github.com/FasterXML/jackson-databind/issues/3168. It seems to me that they're advocating --add-opens usage and struggle to envisage a holistic "fix".

I'd like to avoid adding --add-opens because if it's not jackson, it's the next dependency. I don't want to have to change JVM args across environments because of dependency changes. How do I avoid this?

2 Answers

You don't, JDK internals are encapsulated for a reason.

...

...

Okay, are they gone now?

You can use Overlord by Mackenzie Scott to do various incredibly dangerous things nobody should ever do, including but not limited to:

  • Creating objects without calling their constructors
  • Casting values to incompatible types
  • Managing memory directly, and indeed,
  • Forcibly accessing JDK internals.

Specifically, see (or, rather, don't see) Overlord.breakEncapsulation(Class, Class, boolean) and Overlord.allowAccess(Class, Class, boolean).

From this article it seems that you can avoid resorting to --add-opens by exporting the modules at runtime through the methods of the Burningwave Core library:

  • org.burningwave.core.assembler.StaticComponentContainer.Modules.exportAllToAll()
  • org.burningwave.core.assembler.StaticComponentContainer.Modules.exportPackageToAllUnnamed("java.base","java.lang")
Related