Community
Participate
Working Groups
Installed with Eclipseinstaller, I get the follwoing error on startup eclipse.buildId=4.12.0.I20190605-1800 java.version=1.8.0_222 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE Framework arguments: -product org.eclipse.epp.package.committers.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.committers.product org.eclipse.core.jobs Error Sat Aug 24 07:08:54 CEST 2019 An internal error occurred during: "Update dynamic Java sources working sets". java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer; at jdk.internal.jimage.BasicImageReader.slice(BasicImageReader.java:211) at jdk.internal.jimage.BasicImageReader.intBuffer(BasicImageReader.java:218) at jdk.internal.jimage.BasicImageReader.<init>(BasicImageReader.java:152) at jdk.internal.jimage.ImageReader$SharedImageReader.<init>(ImageReader.java:224) at jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:238) at jdk.internal.jimage.ImageReader.open(ImageReader.java:67) at jdk.internal.jimage.ImageReader.open(ImageReader.java:71) at jdk.internal.jrtfs.SystemImage.open(SystemImage.java:59) at jdk.internal.jrtfs.JrtFileSystem.<init>(JrtFileSystem.java:90) at jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:108) at java.nio.file.FileSystems.newFileSystem(FileSystems.java:336) at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.initialize(JRTUtil.java:368) at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.<init>(JRTUtil.java:350) at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.getNewJrtFileSystem(JRTUtil.java:338) at org.eclipse.jdt.internal.compiler.util.JRTUtil.getJrtSystem(JRTUtil.java:123) at org.eclipse.jdt.internal.compiler.util.JRTUtil.walkModuleImage(JRTUtil.java:158) at org.eclipse.jdt.internal.core.JavaProject.loadModulesInJimage(JavaProject.java:926) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:726) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:1046) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:991) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:968) at org.eclipse.jdt.internal.core.JavaProject.buildStructure(JavaProject.java:482) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:268) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:596) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:326) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:312) at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:267) at org.eclipse.jdt.internal.core.JavaProject.getPackageFragmentRoots(JavaProject.java:2274) at org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater.updateElements(DynamicSourcesWorkingSetUpdater.java:211) at org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater.updateElements(DynamicSourcesWorkingSetUpdater.java:192) at org.eclipse.jdt.internal.ui.workingsets.DynamicSourcesWorkingSetUpdater$1.run(DynamicSourcesWorkingSetUpdater.java:160) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
(In reply to Christoph Laeubrich from comment #0) > java.lang.NoSuchMethodError: > java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer; > at jdk.internal.jimage.BasicImageReader.slice(BasicImageReader.java:211) This would imply that a JDK method (BasicImageReader.slice()) tries to invoke a JDK method (java.nio.ByteBuffer.limit()) which is missing from the JDK. Wow! Please check your JDK installation. Which exact variant / version do you use?
it occurs with openjdk8 and works if i use openjdk9 so maybe a JDK bug but I'm not sure how to track this down.
(In reply to Christoph Laeubrich from comment #2) > it occurs with openjdk8 and works if i use openjdk9 so maybe a JDK bug but > I'm not sure how to track this down. The first test you could make: in the affected openjdk8 find jre/lib/rt.jar and extract (jar x) the files + jdk/internal/jimage/BasicImageReader.class + java/nio/ByteBuffer.class But wait! jdk/internal/jimage is not part of JDK 8. When launching with openjdk8 any chance you additionally have a jrt-fs.jar on the classpath? What is the full commandline shown by ps?
Sorry its Oracle(!) JDK, full version output is: java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) ---- Full comandline () ---- /opt/java/jdk1.8.0_144-x64/bin/java -Dosgi.requiredJavaVersion=1.8 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication -Dosgi.requiredJavaVersion=1.8 -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m -Declipse.p2.max.threads=10 -Doomph.update.url=http://download.eclipse.org/oomph/updates/milestone/latest -Doomph.redirection.index.redirection=index:/->http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/ -Doomph.redirection.platform.runtime=https://git.eclipse.org/c/platform/eclipse.platform.runtime.git/plain/bundles/org.eclipse.core.runtime.releng/platformRuntime.setup->file:/home/christoph/runtime-master/git/eclipse.platform.runtime/bundles/org.eclipse.core.runtime.releng/platformRuntime.setup -Doomph.redirection.platform.ui=https://git.eclipse.org/c/platform/eclipse.platform.ui.git/plain/releng/org.eclipse.ui.releng/platformUi.setup->file:/home/christoph/runtime-master/git/eclipse.platform.ui/releng/org.eclipse.ui.releng/platformUi.setup -jar /home/christoph/runtime-master/eclipse//plugins/org.eclipse.equinox.launcher_1.5.400.v20190515-0925.jar -os linux -ws gtk -arch x86_64 -showsplash -launcher /home/christoph/runtime-master/eclipse/eclipse -name Eclipse --launcher.library /home/christoph/.p2/pool/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.1000.v20190125-2016/eclipse_1801.so -startup /home/christoph/runtime-master/eclipse//plugins/org.eclipse.equinox.launcher_1.5.400.v20190515-0925.jar --launcher.appendVmargs -exitdata 2088011 -product org.eclipse.epp.package.committers.product -vm /opt/java/jdk1.8.0_144-x64/bin/java -vmargs -Dosgi.requiredJavaVersion=1.8 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication -Dosgi.requiredJavaVersion=1.8 -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m -Declipse.p2.max.threads=10 -Doomph.update.url=http://download.eclipse.org/oomph/updates/milestone/latest -Doomph.redirection.index.redirection=index:/->http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/ -Doomph.redirection.platform.runtime=https://git.eclipse.org/c/platform/eclipse.platform.runtime.git/plain/bundles/org.eclipse.core.runtime.releng/platformRuntime.setup->file:/home/christoph/runtime-master/git/eclipse.platform.runtime/bundles/org.eclipse.core.runtime.releng/platformRuntime.setup -Doomph.redirection.platform.ui=https://git.eclipse.org/c/platform/eclipse.platform.ui.git/plain/releng/org.eclipse.ui.releng/platformUi.setup->file:/home/christoph/runtime-master/git/eclipse.platform.ui/releng/org.eclipse.ui.releng/platformUi.setup -jar /home/christoph/runtime-master/eclipse//plugins/org.eclipse.equinox.launcher_1.5.400.v20190515-0925.jar
Your hint about jdk/internal/jimage not part of jdk8 leads into the right direction, i opened preferences > installed JRE It has one entry '/usr/lib/jvm/java-8-openjdk-amd64' named 'java-8-openjdk-amd64' and one entry (marked as default) '/usr/lib/jvm/java-9-openjdk-amd64' named 'JRE for JavaSE-1.8' I tried to remove the entry, but after a restart is automatically is there again.
Moving to Oomph for comments. - How does Eclipse "know" about a JRE that is not the one running Eclipse? - Can a jar file from that unwanted JRE end up on the classpath of Eclipse? - Do env-vars have an impact here?
Just to clarify: Eclipse starts without a problem and i can open files/browse projects but building the Pojects fails then with that error!
This is absolutely not Oomph-related, but I found this explanation: https://github.com/eclipse/jetty.project/issues/3244 Moving back...
So regarding to this [1] comment the Eclipse tooling (??) is compiled with wrong compiler flags? [1] https://github.com/eclipse/jetty.project/issues/3244#issuecomment-495322586
(In reply to Eike Stepper from comment #8) > This is absolutely not Oomph-related, but I found this explanation: > https://github.com/eclipse/jetty.project/issues/3244 > > Moving back... (In reply to Christoph Laeubrich from comment #9) > So regarding to this [1] comment the Eclipse tooling (??) is compiled with > wrong compiler flags? > > [1] > https://github.com/eclipse/jetty.project/issues/3244#issuecomment-495322586 Verry interesting finds! But looking at this stack ... java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer; at jdk.internal.jimage.BasicImageReader.slice(BasicImageReader.java:211) ... wouldn't this imply that jdk.internal.jimage.BasicImageReader is compiled incorrectly???
I don't know much about the EclipseCOmpiler internals, but here in the stack: org.eclipse.jdt.internal.core.JavaProject.loadModulesInJimage it seems to try ti explicitly load Jimage, maybe it is not possible to add a J9 JVM to an Eclipse running on J8 JVM?
Even though now platform requires Java 11 anyways I want to share this link [1] that explains the culprit: If code compile with Java 9 then incompatible byte-code might be produced because of function overloading. [1] https://github.com/eclipse/jetty.project/issues/3244
(In reply to Christoph Laeubrich from comment #12) > [...] I want to share this link [1] That's the one I already shared in comment #8 :P
