> On May 19, 2022, at 7:14 PM, Michael Hall <mik3h...@gmail.com> wrote:
>
>
>
>>
>> Alexander
>>
>>>
>>> I think it will be a problem to implement this for native launchers.
>>
>
> Basically you are telling the developer in
> https://bugs.openjdk.java.net/browse/JDK-8286122
> <https://bugs.openjdk.java.net/browse/JDK-8286122> that it isn’t currently
> possible for their application to get into the Mac App Store as is.
> I was thinking you could possibly in the comments mention the possibility the
> developer could provide these in an archive themselves that they manually
> manage as a workaround.
> Leave them with a possible path forward to achieve this.
> I have successfully done this for something similar if not identical.
>
I think it can work for java commands as well. You have to set them executable
after extraction and point to the embedded jdk lib directory
DYLD_LIBRARY_PATH=JavaCommand.app/Contents/runtime/Contents/Home/lib
JavaCommand.app/Contents/MacOS/JavaCommand
java version "18" 2022-03-22
Java(TM) SE Runtime Environment (build 18+36-2087)
Java HotSpot(TM) 64-Bit Server VM (build 18+36-2087, mixed mode)
I can provide the full JavaCommand source code and jpackage invocation if of
interest. But yes, it works.
From…
String v = rtexec(new String[] {
Paths.get(dataLoc,"java").toString(),"-version" });
System.out.println(v);
You’d have to figure out how to provide the environment variable on the runtime
invocation. That I didn’t verify, but it doesn’t seem impossible.
I added that after getting…
JavaCommand.app/Contents/MacOS/JavaCommand
dyld[5725]: Library not loaded: @rpath/libjli.dylib
Referenced from: /Users/mjh/testLoc/java
Reason: tried: '/libjli.dylib' (no such file),
'/Users/mjh/JavaCommand.app/Contents/app/libjli.dylib' (no such file),
'/Users/mjh/testLoc/./libjli.dylib' (no such file),
'/Users/mjh/testLoc/../lib/libjli.dylib' (no such file),
'/Users/mjh/testLoc/./libjli.dylib' (no such file),
'/Users/mjh/testLoc/../lib/libjli.dylib' (no such file),
'/usr/lib/libjli.dylib' (no such file)
