Re: How to run a program for foreign on java 17 without --add-modules...

[Mark Hammons]

Hi Jorn,

Sadly I'm developing in Scala and there's no jpms support still. I'm able to have a project with both java 19 version and java 17 version on the class path, as long as I'm very careful to use the code that corresponds to the current JVM. It works well, and the only wrinkle is the --add-modules requirement for java 17. However, it's not the end of the world and I'll just document the JVM options needed for each version. 

Thanks for your help,
Mark

On November 3, 2022 7:45:11 PM GMT+01:00, Jorn Vernee <jorn.vernee at oracle.com> wrote:
>> Using a multi-release jar file where the java module-info `requires jdk.incubator.foreign`, and a versioned Java 19 module-info that doesn't require it doesn't seem to be an option either. As the `jar` tool doesn't seem to allow different minor versions of the same class, and for java 19 you need --enable-preview which also changes the minor version of the class file.
>
>Though, if I manually copy the java 19 version of the library class into the META-INF/versions/19 directory, it seems to work as intended when running i.e. the java 17 version of the lib class and module-info is picked up when running on java 17, and the java 19 version of the lib class is picked up when running on java 19 (both using the same command line).
>
>Maybe this is just a case of the jar validator being too strict...
>
>Jorn
>
>On 03/11/2022 19:35, Jorn Vernee wrote:
>> Hi Mark,
>> 
>> Sorry for the late reply.
>> 
>> As far as I know there is no way to ignore --add-modules for a non-existing module. This is one of the features of the module system, and prevents missing module errors halfway through running.
>> 
>> java.base has multiple qualified experts to jdk.incubator.foreign, and for that to work, it seems they need to be in the seem module layer. java.base also needs to be in the boot layer. So, creating a dynamic module layer with the jdk.incubator.foreign module and your library's module doesn't seem to be an option. (there will be an exception when the jdk.incubator.foreign code tries to access something internal from java.base, even though there is a qualified export).
>> 
>> Using a multi-release jar file where the java module-info `requires jdk.incubator.foreign`, and a versioned Java 19 module-info that doesn't require it doesn't seem to be an option either. As the `jar` tool doesn't seem to allow different minor versions of the same class, and for java 19 you need --enable-preview which also changes the minor version of the class file.
>> 
>> Maybe someone else has another idea on how to do this.
>> 
>> Jorn
>> 
>> On 25/10/2022 16:53, Mark Hammons wrote:
>>> Hi all,
>>> 
>>> I've finally achieved a milestone I was fighting hard for in my library (https://github.com/markehammons/slinc), support for multiple versions of foreign with the same program. I have a runtime test configured on that project that takes on its classpath the Slinc-j19 runtime and the Slinc-j17 runtime, chooses the correct implementation at runtime based on the host jvm, and executes code the same (so far). The one fly in the ointment is the command-line requirements for foreign on java 17. "--add-modules=jdk.incubator.foreign" won't work on java 19 for obvious reasons, but I can't find a way to get the jvm to ignore the missing module, nor can I find a way to get java 17 foreign to work without that command line option. Do you all have any solution?
>>> 
>>> The main draw for this is to make it very easy for library or application devs to write one version of their project and not have to select the correct set of jvm command line options in order to get their project working.
>>> 
>>> Thanks,
>>> Mark
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221103/3912c1c9/attachment.htm>