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.bate...@oracle.com> wrote:
>
>
> On 09/10/2015 20:33, Chris Hegarty wrote:
>> On 9 Oct 2015, at 20:26, Alan Bateman <alan.bate...@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.
