"it should never attempt to use the native implementation” This is confusing.
It’s attempting to see if a native library is present otherwise use java. Is
this the wrong approach?
> On Oct 9, 2015, at 4:18 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> On 09/10/2015 19:59, Chris Hegarty wrote:
>> This is a little temporary solution to get the jrt-fs up and running again
>> with JDK 8, until JDK-8137017 [1] can be resolved.
>>
>> It is fair game for an unchecked Exception or Error thrown during
>> class initialization to result in a NCDFE. The code in BasicImageReader
>> should catch java.lang.LinkageError, rather than UnsatisfiedLinkError
>> ( LinkageError is the supertype of NCDFE and UnsatisfiedLinkError ),
>> so that it falls over the the Java implementation when libjimage is not
>> in the runtime image.
>>
>> 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 (LinkageError ex) {
>> substrate = ImageJavaSubstrate.openImage(imagePath, byteOrder);
>> }
>>
> I realize this is a temporary fix but what is the specific exception that is
> thrown here (just asking catching LinkageError could hide other issues here)?
> Do we have an issue submitted to fix the real issue here as it should never
> attempt to use the native implementation when on JDK 8 or when targeting a
> different run-time image.
>
> -Alan
