Community
Participate
Working Groups
Created attachment 273134 [details] Sample project Version: Oxygen.3 (4.7.3) Build id: M20180221-1700 Use Java 10 patch of http://download.eclipse.org/eclipse/downloads/drops4/P20180313-0940/ 1) Launch eclipse with Java 10 2) Import the attached project 3) Set API baseline option to ignore 4) Clean -> Build All 5) Set Build automatically to true 6) Remove Java 10 from installed JRE 7) Add Java 9 in installed JRE you will get the following build error. Clean -> build all also doesnt work. I need to close eclipse and open again to build this project with Java 9 !STACK 0 java.lang.BootstrapMethodError: java.lang.LinkageError: loading constraint violation when overriding method "jdk/internal/jimage/ImageReader$SharedImageReader$LocationVisitor.visit(Ljdk/internal/jimage/ImageLocation;)V" during creation of class "jdk/internal/jimage/ImageReader$SharedImageReader$$Lambda$576/000000000CA0E780": loader "java/lang/InternalAnonymousClassLoader@34e1342" of class "jdk/internal/jimage/ImageReader$SharedImageReader$$Lambda$576/000000000CA0E780" and loader "java/net/URLClassLoader@4d9dd4a5" of class "jdk/internal/jimage/ImageReader$SharedImageReader$LocationVisitor" have different types for the method signature at jdk.internal.jimage.ImageReader$SharedImageReader.handlePackages(ImageReader.java:389) at jdk.internal.jimage.ImageReader$SharedImageReader.buildNode(ImageReader.java:304) at jdk.internal.jimage.ImageReader$SharedImageReader.findNode(ImageReader.java:489) at jdk.internal.jimage.ImageReader.findNode(ImageReader.java:104) at jdk.internal.jrtfs.SystemImage$1.findNode(SystemImage.java:64) at jdk.internal.jrtfs.JrtFileSystem.lookup(JrtFileSystem.java:457) at jdk.internal.jrtfs.JrtFileSystem.checkNode(JrtFileSystem.java:490) at jdk.internal.jrtfs.JrtFileSystem.getFileAttributes(JrtFileSystem.java:216) at jdk.internal.jrtfs.JrtPath.getAttributes(JrtPath.java:645) at jdk.internal.jrtfs.JrtFileSystemProvider.readAttributes(JrtFileSystemProvider.java:337) at java.nio.file.Files.readAttributes(Files.java:1748) at java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:230) at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:287) at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:333) at java.nio.file.Files.walkFileTree(Files.java:2673) at java.nio.file.Files.walkFileTree(Files.java:2753) at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.walkModuleImage(JRTUtil.java:403) at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.initialize(JRTUtil.java:209) at org.eclipse.jdt.internal.compiler.util.JrtFileSystem.<init>(JRTUtil.java:184) at org.eclipse.jdt.internal.compiler.util.JRTUtil.getJrtSystem(JRTUtil.java:111)
Is there anyone else who faces this issue?
If I read the error correctly, then it complains about incompatible classes loaded in the realm of jdk/internal/jimage/ImageReader$SharedImageReader$* more specifically, ..$$Lambda$576/000000000CA0E780 doesn't match to its contract jdk/internal/jimage/ImageReader$SharedImageReader$LocationVisitor.visit(Ljdk/internal/jimage/ImageLocation;)V If we assume that all classes are read from the same JDK then it would indicate a bug / corruption in those System Libraries. I just wonder if the call to FileSystems.newFileSystem(JRTUtil.JRT_URI, env) could possible trigger loading classes from the target URI? If so, then switching JRE installations could lead to loading the same set of classes from different libraries. Hard to believe, though. Note that I speak of *loading* JRT classes into the current VM, not of using JRT classes to read the image. Perhaps classloader breakpoints on the classes shown in the stack trace will provide more information.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
