RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate (original) (raw)

Jim Laskey (Oracle) james.laskey at oracle.com
Fri Oct 9 19:43:25 UTC 2015

I’m still missing something. How does the jrtfs code ‘know’ it’s in a jar vs part of the jdk9 runtime?

On Oct 9, 2015, at 4:37 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

On 09/10/2015 20:33, Chris Hegarty wrote: On 9 Oct 2015, at 20:26, Alan Bateman <Alan.Bateman at oracle.com> wrote:

I looked more closely at this and I think it's best to handle NCDFE rather than the more general LinkageError. Ok, I make the follow change before pushing: diff --git a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java --- a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java +++ b/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java @@ -58,7 +58,7 @@ try { substrate = ImageNativeSubstrate.openImage(imagePath, byteOrder); - } catch (UnsatisfiedLinkError ex) { + } catch (UnsatisfiedLinkError | NoClassDefFoundError ex) { substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder); } This looks fine.

But I hope very temporary, we need to get this code fixed so do the right thing. I added the follow to JDK-8137017, to ensure this is not forgotten: jrt-fs.jar should not depend, directly or indirectly, on JDK internal native libraries, e.g. libjimage. Thanks.

More information about the core-libs-dev mailing list