> On May 19, 2022, at 5:38 PM, Alexander Matveev <alexander.matv...@oracle.com> 
> wrote:
> Hi Michael,


> I think it will be a problem to implement this for native launchers.

Each of the native commands is it’s own app launcher? I didn’t know this. I 
don’t think it was ever really indicated in the discussion why the commands 
needed the embedded plist. I think Apple DTS guessed it had something to do 
with a TCC issue.

> - If we extract native launchers inside installed app bundle it will 
> invalidate signature and most likely will require privileged permissions to 
> write inside app bundle.

I thought maybe jpackage unsigned and resigned the jdk itself. Maybe not. I was 
talking about simply including a jar in input that ends up in the ‘app’ 
directory and the app then has the jar contents extracted from there. No 
additional write permission’s are required. 

> - If we extract to some known and accessible location as you suggesting, then 
> how our launchers will figure out which runtime to use? All other runtime 
> files will be inside app bundle.

Again this possibly my not understanding what additional requirements there are 
for the commands to be ‘launchers’. I was thinking if the embedded plist was 
still a problem the developer could possibly use commands from a compatible 
linux distribution. OS/X and linux are both Unix right? It did occur to me that 
extracting native commands out of a jar might lose the executable posix 
permission. I’m not sure if jar has any builtin meta information to retain 
these permissions or if nio allows you to set executable. I haven’t had to 
address this. 

> - If user deletes application, then how we will cleanup extracted files? Most 
> likely it will require uninstall script in known location which user will 
> need to run in order to cleanup extracted files.

I haven’t tried to address this yet myself for my application. I’m not sure a 
lot of OS/X application’s do. But it would probably be up to the app to provide 
an uninstall of some kind. Some app’s are obviously going to need external data.

> Thanks,
> Alexander

Again I’m suggesting it as a roughed out workaround suggestion for the 
developer. There might be issues they would need to work out and might even be 
problems where it won’t work.
I’m not suggesting it as a fix you would try to implement.


Reply via email to