39

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?

Robert Bain
  • 9,113
  • 8
  • 44
  • 63
  • 25
    You stop upgrading to the latest versions of Java faster than popular Java software can support. – Gilbert Le Blanc Aug 20 '21 at 21:07
  • @GilbertLeBlanc it's a fair point and you could be right. It's my concern/suspicion that yet another `--add-opens` will be the prescription long term though. These frameworks need to do some cheeky things I'm not sure there are alternatives for. – Robert Bain Aug 20 '21 at 21:18
  • 13
    it is pretty much the same. People from jdk say - "don't use Unsafe, really." people still do. "we will deprecate it its usage", people still use it. "that's it, it has been 10 years already". but you are breaking our frameworks!!! I do not know exactly who is to blame, but the fact is there. We personally stopped upgrading at jdk-16 and can't move to jdk-17 for multiple libraries. We slowly either remove them, or work fixing the defects, or watch closely when that happens. It's complicated, I agree with you. – Eugene Aug 21 '21 at 13:14
  • 5
    there is a good discussion [here](https://www.reddit.com/r/java/comments/n2j9pw/a_peek_into_java_17_continuing_the_drive_to/) also – Eugene Aug 21 '21 at 13:20
  • 1
    There exists a terrible hack that allows to open arbitrary packages from code to the calling module at runtime. It uses `sun.misc.Unsafe` and some implementation-dependent knowledge. It still works on Java 17 GA but may break at any time in the future. I can give you a hint if you are nonetheless interested. – Stefan Zobel Sep 15 '21 at 17:33
  • 1
    I've yet to see widespread adoption of JPMS. I suspect the only software it helped is the JDK itself. @GilbertLeBlanc `--add-opens` flag has been around since Java 9 (Sep 2017); if "popular Java s/w" don't support it by now, they have no burning incentive to support ever. – Abhijit Sarkar Sep 18 '21 at 20:24
  • @StefanZobel looking at unsafe, I don't really see how that allows access... hint definitely needed – Jonathan S. Fisher Jul 29 '22 at 21:38
  • 1
    @JonathanS.Fisher See for example https://github.com/stefan-zobel/wip/blob/master/src/main/java/misc/AddOpens.java I believe the idea originated in Project Lombok but I don't have a reference at the moment. – Stefan Zobel Jul 30 '22 at 10:59
  • Thanks. That got me to the finish line. Appreciate it – Jonathan S. Fisher Jul 31 '22 at 00:58

2 Answers2

2

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")
JulesF
  • 19
  • 3
Juan Pablo Medina Adame
  • 83
  • 2
  • 3
    As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jun 07 '22 at 01:14
-2

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).

bluelhf
  • 71
  • 1
  • 7
  • Looks very interesting. But sadly it uses sun.misc.Unsafe internally, so it's not a viable replacement in the event of Unsafe biting the dust. – barneypitt Oct 08 '22 at 10:23