How to debug Java runtime unnamed modules errors with hashed names

Question

I'm into modular Java for a few months now, with Spring and related ecosystem stuff. And one of the most frustrating experiences is debugging module issues with unclear names

Here is the last error of this kind I got:

java.lang.IllegalAccessError: superclass access check failed: class com.oracle.truffle.polyglot.PolyglotImpl (in unnamed module @0x58a90037) cannot access class org.graalvm.polyglot.impl.AbstractPolyglotImpl (in module org.graalvm.sdk) because module org.graalvm.sdk does not export org.graalvm.polyglot.impl to unnamed module @0x58a90037

@0x58a90037 is the problem here.

Depending on what I am going, I will randomly try spring.beans, spring.context, javax.validation etc... And open my module to the world, which somehow removes the value of encapsulating them in the first place.

For this specific case, I tried requires org.graalvm.sdk; which didn't got well, but requires org.graalvm.js; did it.

Debugging by random attempts doesn't really seem like a smart way of tackling these issues. So I wonder how you guys do it.

Thank you!

Ethanol

Unfortunately, the best way I've come across is to look at the class name that's in the unnamed module. In your case, that's com.oracle.truffle.polyglot.PolyglotImpl. If you know the library well enough, or if the package name is sufficiently descriptive, then you can simply deduce what module the class "should" be in. Otherwise you need to inspect the modules to figure out which one contains that class. I haven't had much cause to do that sort of thing, but I'd expect it can be done with command line tools (Java tools and/or external tools). – Xerography

I see. I tried that, and it happened that com.oracle.truffle.polyglot.PolyglotImpl is part of truffle-api-<version>.jar. – Ethanol

From there you can use jar --describe-module --file truffle-api-<version>.jar to get the module name. – Xerography

These are automatic modules (derived from the jar file name) – Ethanol

It will still give you the module name. Also, note that the name of an automatic module can be made explicit via the Automatic-Module-Name manifest entry. Only if that entry doesn't exist and there's no module-info descriptor will the module name be derived from the JAR file name. – Xerography

The “unnamed module” contains classes not actually belonging to a module, in other words, which have been loaded through the old class path. Don’t specify jars on the class path when they’re supposed to be loaded as modules. Only specify them on the module path. Then, you shouldn’t have that problem. – Korykorzybski

@Korykorzybski Not sure this is as much a problem nowadays, but sometimes IDEs/build tools would put dependencies on both the class path and the module path. I saw this problem a lot with JavaFX, where you would manually configure the --module-path but the IDE would still put the dependencies on the --class-path as well. That would often lead to IllegalAccessErrors similar to the one in this question. – Xerography

I don’t understand what you hope to gain from a bounty when you keep ignoring the comments. The hexadecimal number is not the problem. The presence of an “unnamed module” is. You have to ensure that classes from modules do not appear on the old class path. Once you have fixed your environment, your problem isn’t a problem anymore. If you have reasons to assume that this won’t help or have questions about it, fell free to add them. – Korykorzybski

Slaw and Holger have already provided good enough details. Just to add to it, here is a useful resource for you to understand the concepts like types of modules involved in the platform. Additionally, there is a way through which you could observe the module resolution during your application startup. – Booster