RuntimeException: Package jdk.internal.jimage.decompressor in module jrt.fs and module java.base

Question

Component Details - Using IntelliJ IDEA 2017.1 CE and jdk-9-ea+154

main() -

Set<String> set2 = Set.of("a", "b", "c");
set2.forEach(System.out::println);

module-info.java

module collection {
    requires java.base;
}

Logs -

Error occurred during initialization of VM
java.lang.RuntimeException: Package jdk.internal.jimage.decompressor in both module jrt.fs and module java.base
    at jdk.internal.module.ModuleBootstrap.fail(java.base@9-ea/ModuleBootstrap.java:699)
    at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:329)
    at java.lang.System.initPhase2(java.base@9-ea/System.java:1928)

Doubtful over the implementation of initialization of VM, my question is that I haven't included module jrt.fs - Where is it coming in the picture from? How do I debug such modules inclusion/exclusion? How do I further solve the current exception?

Promycelium

This is really weird, I never heard of jrt.fs. Which JDK version (build number?) are you running? Also, try looking for the module with java --list-modules. – Schoolbook

@Nicolai Using jdk-9-ea+154 currently. Would look into the details of modules.Any idea over what jrt.fs is used for? Might help in getting to know. – Promycelium

Answer 1

$JAVA_HOME/lib/jrt-fs.jar contains a copy of the "jrt" file system provider compiled to JDK 8. It's for tools such as IDEs that run on JDK 8 but need to access a JDK 9 run-time image.

From the exception then it does appear that this JAR file, or maybe $JAVA_HOME/lib, has been put on the module path in error. JAR files that do no contain a module-info.class in the top-level directory are treated as automatic modules so this is why the exception has "module jrt.fs" in the message. The exception basically just means that you've ended up with two modules containing the jdk.internal.jimage.decompressor package (and many other packages) due to putting jrt-fs.jar on the module path.

Melodramatize

So how do you actually fix the problem? – Tolbutamide

@Tolbutamide mv $JAVA_HOME/lib/javafx* $PATH_TO_FX. I made $PATH_TO_FX a subfolder of $JAVA_HOME/lib called javafx_modules, and now it works. I wonder why this is not default, anyway. – Antipode

@Antipode Add that comment to your answer and I'll remove my down vote (ping me in the comment to let me know when you've done it). – Tolbutamide

It is not my answer, and if people can see the original answer, they can also see the comment. No need to edit other's OC. The answer does explain why it doesn't work, so I see no reason to downvote it. – Antipode

Answer 2

I got the same error under Arch Linux. The package java-openjfx installs its libraries into the lib directory of the openjdk, which seems to cause problems. I found a workaround by adding not the whole lib directory but only the needed libraries instead.

In project structure > Libraries > + > Java > /usr/lib/jvm/default/lib > select needed libraries (holding ctrl) should look something like this

Then in Run Configurations set the VM Options accordingly

    --module-path /usr/lib/jvm/java-14-openjdk/lib/javafx.base.jar:/usr/lib/jvm/java-14-openjdk/lib/javafx.controls.jar:/usr/lib/jvm/java-14-openjdk/lib/javafx.graphics.jar --add-modules=javafx.controls

For my project it was enough to only add controls as module but the path to base and graphics were required to get it to run.

Faxan

This is what my problem was. I'm using javafx.controls and javafx.fxml both. I had to add --module-path /usr/lib/jvm/java-11-openjdk/lib/javafx.controls.jar:/usr/lib/jvm/java-11-openjdk/lib/javafx.fxml.jar:/usr/lib/jvm/java-11-openjdk/lib/javafx.graphics.jar:/usr/lib/jvm/java-11-openjdk/lib/javafx.base.jar --add-modules javafx.controls,javafx.fxml Just add the modules first and It will warn you about missing libraries when running. If not just add them all one by one – Conductivity

IMO this should be the accepted solution: in certain environements (e.g. Arch/Aur) both JDK and JavaFX libs are mixed in the same folder and cause the issue described by OP. This solution keeps libs where the packages managers expect them and only impact the lauchers leveraging JavaFX. A bit tedious but could also be comoditized with an ad-hoc variable in user´s .xxxshrc for instance. – Some

Answer 3

I had the same issue on Manjaro Linux, while it was working fine on windows. Looking at the differences it became clear that the javafx 11 package installs into /lib/jvm/java-11-openjdk/lib, which I then set as PATH_TO_FX. This seems to be the issue, because jrt-fs.jar is in the same folder.

I moved all files from fx to a separate folder and then set that as PATH_TO_FX. Now it works fine.

Lemley

This workaround is dirty. So now you get a random directory not managed by pacman that will just sit there for eternity? – Heterozygous

I am not happy with the solution, but the pacman package just does not work. Do you have a cleaner suggestion? – Lemley

No still looking, will post here if I find one – Heterozygous

Answer 4

To fix this problem, please follow the below steps. 1- Right-click on your class. 2 - Run AS-> Run Configurations 3. Click on main -> Click on the Browse option and Choose your project name in project. Click on the Apply button and after processing click on the Run button.

Fruitful

That solved this problem. Thanks for the solution -- it is clean. I believe that in a previous version, Eclipse would set automatically the project name to the Run Configuration, for I can't remember the same error in the past. – Raceway

Answer 5

Try to remove jrt-fs.jar from the directory of jdk9. I did it in Project Structure in IntelliJ IDEA and it works fine for me

Yoko

Worked for me too... though I'm also unable to load resources from classloader, likely due to missing the FileSystem module jrt.fs. To be fair, I haven't verified yet that the code in question works in any other java 9 environment (it is correct in 8 and lower) – Pyszka

Answer 6

In Eclipse, changing the Eclipse workspace or deleting the .metadata folder in the workspace folder worked for me.

I don’t know what fixed it, but if I had to guess it could be something in the .metadata folder that caused the exception.

Pineda

Consider adding more information about your answer, like why does it work and that stuff – Arlyn

@Arlyn I don’t know why it worked. I just wanted to offer an solution for the people who might be having the same problem. The answer that is marked to solve the problem doesn’t clearly tell you how to fix the problem, it just says the cause of the problem, which atleast for me was hard to understand. – Pineda

But if I had to guess it’s something about the .metadata folder that affects the program. – Pineda

@Arlyn Thanks for the suggestion! – Pineda

Answer 7

I faced this issue for Spring Toolsuite 4, The metadata contains info about the present projects in the workspace, and common eclipse settings like font, codestyle, run configurations settings and sometimes information about modules used, eclipse plugins & eclipse log file for eclipse log errors, etc.

It does not contain valuable project info.

If this folder is deleted or changed manually, eclipse sees this directory as a new fresh workspace. You have to import the existing projects again and you are done.

If you want to keep your fonts, codestyle etc you can export / import these preferences for new workspaces or create a backup of .metadata.

In my case it worked for above issue of Package jdk.internal.jimage.decompressor in module jrt.fs and module java.base when i deleted .metadata folder, import project again, setup run configuration and everything started working.

Saturate

Answer 8

remove the .metadata folder, then restart eclipse.

Diaphoresis

Answer 9

I had the same issue on a Mac Eclipse Version: 2020-09 (4.17.0)

Whenever I tried to run my existing Configuration I got that error. I tried all kinds of workarounds but nothing worked.

So I created a new Configuration:

1. Open file containing main() method.
2. From Run menu select "Run As >> Java Application"

That ran OK. The advantage of this is that it does not modify your JDK installation.

Sufficient

Answer 10

Removing the .metadata folder in the workspace folder works for me.

(I'm using Windows with Eclipse 2021-06 (4.20.0))

Remainder