JPackage with a modular application fails to load record class files even with --enable-preview

[Andy Herrick]

I tried a simple testcase with 14.0.2 and with 15, and if failed as 
indicated with 14.0.2 but worked fine in 15.

/Andy

On 6/9/2020 10:53 AM, Johannes Kuhn wrote:
> Relevant StackOverlow question: 
> https://stackoverflow.com/questions/61504956/records-in-jlinked-application-throws-exception
>
> It talks about JLink, but the error message is the same, so I expect 
> the same root cause:
> The ASM version shipped with JDK 14 doesn't support records yet. It is 
> already fixed for JDK 15.
>
> - Johannes
>
> On 09-Jun-20 16:40, Andy Herrick wrote:
>> So when you use the jpackage option "--java-options --enable-preview" 
>> it appears to work with a non-modular jar, but not with a modular jar ?
>>
>> I think I can create a testcase for that.
>>
>> Have you tried it with the jpackage from a preview release of JDK15  
>> (https://jdk.java.net/15/) ?
>>
>> Can you look at the runtime in the app-image of the failing case, and 
>> see if the preview module is there ?  Perhaps the problem is the way 
>> jpackage invokes jlink.
>>
>> A final thing you can try is run jlink yourself, and use the 
>> resulting runtime-image in jpackage args.
>>
>> /Andy
>>
>> On 6/7/2020 9:07 AM, Markus Jevring wrote:
>>> I have this app, which uses Java 14 with –enable-preview and 
>>> records. If I turn it in to a normal non-modular jar, it works with 
>>> both java -jar –enable-preview myapp.jar, and with a native image 
>>> built with jpackage. However, when i turn it into a modular jar, I 
>>> can still launch it with java –enable-preview –module-path ... 
>>> –module ..., but  when I try to create a native image using jpackage 
>>> usign the same modular flags, launching it fails. I get a dialog box 
>>> saying “Failed to launch JVM”, and if I enable –win-console when I 
>>> build it and relaunch it, it tells me this:
>>>
>>> Exception in thread "main" java.lang.ClassFormatError: Invalid 
>>> constant pool index 31 for name in Record attribute in class file 
>>> net/jevring/frequencies/v2/input/KeyTimings$Note
>>>          at java.base/java.lang.ClassLoader.defineClass2(Native Method)
>>>          at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
>>>          at 
>>> java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
>>>          at 
>>> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown 
>>> Source)
>>>          at 
>>> java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(Unknown 
>>> Source)
>>>          at 
>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown 
>>> Source)
>>>          at 
>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown 
>>> Source)
>>>          at 
>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown 
>>> Source)
>>>          at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
>>>          at 
>>> frequencies/net.jevring.frequencies.v2.input.KeyTimings.<init>(Unknown 
>>> Source)
>>>          at 
>>> frequencies/net.jevring.frequencies.v2.Thief.<init>(Unknown Source)
>>>          at frequencies/net.jevring.frequencies.v2.Main.main(Unknown 
>>> Source)
>>>
>>> Note, above, is a record. I tried moving it out to a separate class, 
>>> and I still got the same error. When I converted Note to a normal 
>>> class, it started complaining about the next record it cound.
>>> I know that it’s picking up the –enable-preview java option, because 
>>> when I omit that, it complains about the class file version being 
>>> wrong.
>>>
>>> Since I can run it just fine using “java -jar”, and it works fine 
>>> under all other circumstances, I must conclude that there’s 
>>> something wrong with the intersection of modular jars and jpackage.
>>> I’ve googled around plenty, and I haven’t found anything that might 
>>> help me. I’m not sure if this is a call for help or a bug report, 
>>> though I’d like to consider it the latter =)
>>>
>>> I put what I had on a branch: 
>>> https://bitbucket.org/jevring/frequencies/branch/java-modules
>>> I realize it’s not a small self-contained example that replicates 
>>> the issue, and for that I’m sorry. If someone is interested about 
>>> this, I could try to make one.
>
>