How to run a program for foreign on java 17 without --add-modules...
Jorn Vernee
jorn.vernee at oracle.com
Thu Nov 3 18:35:01 UTC 2022
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
>
More information about the panama-dev
mailing list