jpackage and alternate JRE's - OS X

[Michael Hall]

> On Mar 17, 2020, at 3:28 PM, Andy Herrick <andy.herrick at oracle.com> wrote:
> 
> yes jpackage itself will not do any signing unless you use the various signing option(s).
> 
> But the executables in the jdk itself are signed, including those packaged as a resource like jpackageapplauncher itself.
> 
> The app executable itself, in your case FastRGraalHP.app/Contents/MacOS/FastRGraalHP, is a copy of jpackageapplauncher
> 
> /Andy
> 
> On 3/17/2020 4:04 PM, Michael Hall wrote:
>> 
>>> 
>>> codesign -dv outFastR/FastRGraalHP.app
>>> Executable=/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP
>>> Identifier=jpackageapplauncher
>>> …
>>> 
>>> It does appear that jpackage is doing some default code signing.
>>> 
>> Running verbose I see no indication, other than maybe the above, that jpackage is in fact code signing. If this is something Apple is doing and GraalVM is doing something to violate it then it is definitely not something jpackage can probably do anything about.
>> 

OK thanks. Graal seems to do some access control requiring 

Context context = Context.newBuilder().allowNativeAccess(true).build();

Or allowAllAccess()

Must be some issue of theirs or something I just haven’t figured out being new to it.