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

[Jorn Vernee]

 > 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
>>