OS : Ubuntu 20.04
JVM : Zulu 11
I did a fresh eclipse-install of OpenHab 3 development environment. Resolved app.bndun but when I launch it :
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package jdk.internal.jimage.decompressor in both module java.base and module jrt.fs
Not much clues on the web on how to sort this. Installed 10th times, tried with another JVM (Zulu, OpenJDK…), no progress.
Can someone help me ?
You might have seen this post already: https://stackoverflow.com/questions/42986287/runtimeexception-package-jdk-internal-jimage-decompressor-in-module-jrt-fs-and
Looks like some other library build for another java version might cause this problem. Do you have another java version installed? or something might be on the path, somewhere?
No, no previous version in the path.
I did this, and it worked :
sysadmin@glhdev:/usr/lib/jvm/zulu-11-amd64/lib$ sudo mkdir jrtfs
sysadmin@glhdev:/usr/lib/jvm/zulu-11-amd64/lib$ sudo mv jrt-fs.jar ./jrtfs/
… to quick… it worked for the demo.app but when I added a binding it complained again about jrt-fs.jar missing.
Will try to clean everything and restart once again.
Will track here my installation so it maybe can help :
JAVA_HOME=/usr/lib/jvm/jdk-11.0.8 to path.…installation ongoing…
… same result 
:
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package jdk.internal.jrtfs in both module jrt.fs and module java.base
@hilbrand : I wonder why eclipse installer talks of JRE 1.8 here :
Because that is in the openHAB eclipse setup file. This still needs to be updated to java 11.
Also on the first setup page it also asks for selecting a jvm. I assume you also selected java 11 there?
Well, I had to install JDK v8, 11, 14 to have something that seems to work but now it does not pick-up currently opened binding. I think I’m going to wait a full step by step set-up of the environment because I run out of ideas on how to make it work…or I’ll try to do it using VS Code.
Did a fresh new install of Eclipse on Windows this time. I had to install both JDK 8 and 11.
It seems to work, once Eclipse configured like this :
The JVM launched is the right one and starts :
FYI I just did a fresh install as I’m switching over to 3.0 for my development. Even though I selected Java 11 at install time, I still had to enter Java 11 under Window->Preferences.
If Java 8 is selected like you have it, Eclipse autocomplete (or whatever it’s called) won’t show any of the Java 11 methods. At least that was the case for me.
Not sure if I have or not Java 11 methods, I at least see deprecated since Java 9 versions - and if I switch to Java 11 in Preferences, I’m stuck with this :
My 3.0 dev environment (Eclipse 2020-09 and Zulu 11.0.8 on Windows 10) was working fine until yesterday. Then because of a library update I had to clear the .m2 cache directory to get a binding build working again. After that I was able to build from the command line with maven again, but I couldn’t run/debug under Eclipse anymore. I tried doing a Maven/Update Project on both the binding I’m working on and org.openhab.demo.app. Then I tried to re-resolve app.bndrun, and got an error. So then I updated openhab-distro by doing a pull on it, and after merging in my local changes again I was able to resolve app.bndrun. But then when I clicked “Run OSGi”, I got the error mentioned above in my console window:
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package jdk.internal.jimage in both module java.base and module jrt.fs
It seems like this may be caused by something wrong in Eclipse’s workspace directory. When I created a new workspace and re-imported openhab-distro and my binding from openhab-addons, I was able to get it working again. Unfortunately, I’m not quite sure how to configure the new workspace properly without the automatic setup. For one thing, Eclipse complained about not being able to find spotless when I did the maven import. It gives the option to ignore that plugin so you can move on, but that ends up updating the binding’s pom.xml file, so it’s not a long-term solution.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.