Re: [External] : Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

[Michael Hall]

> On Jun 7, 2022, at 9:21 PM, Alexander Matveev  
> wrote:
> 
> Hi Michael,
> 
> Yes, this is correct. It is a three step process as you outlined it below.
> 

Alexander,

Could you post an example of the three invocations, without needing to include 
any post-processing, to 1) create app-image 2) sign 3) add to DMG
Or indicate any tests included, or that will be included, in the jdk source 
where something similar is done. 
There are not yet that I know of any documentation pages for the command? 

Thanks,
Mike

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

[Michael Hall]

Alexander,

I had an existing local GitHub repo for the jdk I updated that appeared to 
accept the parameters you indicated. It generated a jdk 19. 

If you are saying I’m not getting the main branch or the update for some reason 
has dependencies I’m not getting I would have to determine how to correctly get 
these, or, I guess wait for a release that has all the necessary. Determining 
if this worked as expected before a release seemed like it would be a good idea.

Yes, the point of my original suggestion was to allow generating the 
application unsigned, then do post-processing - like modify the default 
Info.plist, and finally separately sign.

I thought your change provided the means to do this by first generating an 
unsigned image using —type app-image, then on a separate invocation indicate 
the app-image and sign and package it. 

> ./build/*/images/jdk/bin/jpackage --type app-image --app-image

If I follow you now it isn’t a two step but a three step process.

1) Generate unsigned application and do post-processing.

2) Sign modified app-image

3) DMG or PKG the modified and signed app-image

Is this correct?

Thanks,
Mike

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

[Michael Hall]

> 
> ./build/*/images/jdk/bin/jpackage --app-image 
> ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
> --mac-signing-key-user-name "Developer ID Application: Michael Hall 
> (5X6BXQB3Q7)"
> Bundler Mac DMG Package skipped because of a configuration problem: When 
> using an external app image you must specify the app name. 
> Advice to fix: Set the app name via the -name CLI flag, the 
> fx:application/@name ANT attribute, or via the 'appName' bundler argument.
> 
> ./build/*/images/jdk/bin/jpackage --app-image 
> ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
> --mac-signing-key-user-name "Developer ID Application: Michael Hall 
> (5X6BXQB3Q7)" --name HalfPipe
> Warning: Using unsigned app-image to build signed dmg.
> 
> *** The app-image was actually a signed one. I’m not sure that matters. Also 
> since this would normally be my intention should there be a warning? ***
> 
> codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its 
> Designated Requirement
> 
> *** Seems successful ***
> 
> Thanks again.
> 

Possibly my mistake somehow but codesign seems to flag something if the 
application is actually unsigned.

${PACKAGER} \
--verbose \
--add-modules java.desktop,java.prefs,java.se \
--type app-image \
--input ./input \
--app-version 1.0  \
--name BlackJack\ Blastoff_Unsigned \
--main-jar bjb.jar \
--main-class org.bjb.BlackJackApp \
--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50  
-Dapple.laf.useScreenMenuBar=true 
-Dcom.apple.mrj.application.apple.menu.about.name=BlackjackBlastoff 
-Dapple.awt.application.name=Blackjack\ Blastoff’ 

[19:41:02.231] Creating app package: BlackJack Blastoff_Unsigned.app in 
/Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg
[19:41:05.516] Command [PID: -1]:
jlink --output /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack 
Blastoff_Unsigned.app/Contents/runtime/Contents/Home --module-path 
/Library/Java/JavaVirtualMachines/jdk-18.jdk/Contents/Home/jmods --add-modules 
java.desktop,java.prefs,java.se --strip-native-commands --strip-debug 
--no-man-pages --no-header-files
[19:41:05.517] Output:

[19:41:05.518] Returned: 0

[19:41:05.545] Using default package resource JavaApp.icns [icon] (add 
BlackJack Blastoff_Unsigned.icns to the resource-dir to customize).
[19:41:05.547] Preparing Info.plist: 
/Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack 
Blastoff_Unsigned.app/Contents/Info.plist.
[19:41:05.547] Using default package resource Info-lite.plist.template 
[Application Info.plist] (add Info.plist to the resource-dir to customize).
[19:41:05.550] Using default package resource Runtime-Info.plist.template [Java 
Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize).
[19:41:05.551] Succeeded in building Mac Application Image package

./build/*/images/jdk/bin/jpackage --app-image 
~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign 
--mac-signing-key-user-name "Developer ID Application: Michael Hall 
(5X6BXQB3Q7)" --name BlackJack_Blastoff_Unsigned
Warning: Using unsigned app-image to build signed dmg.

 open BlackJack_Blastoff_Unsigned-1.0.dmg   
  
codesign -v --verbose=4 /Volumes/BlackJack_Blastoff_Unsigned/BlackJack\ 
Blastoff_Unsigned.app
/Volumes/BlackJack_Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: code has 
no resources but signature indicates they must be present

I am using the installed jdk18 to create the app-image. Would that need to be 
done with the same jdk with the changes applied? 

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

[Michael Hall]

> On Jun 5, 2022, at 8:56 AM, Michael Hall  wrote:
> 
> 
> Fwiw, I was going to take a look at this but my build failed.
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_liblcms_cmstypes.o:
> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132:
>  error: parameter 'SizeOfTag' set but not used 
> [-Werror,-Wunused-but-set-parameter]
> void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, 
> cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>   
> ^
> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125:
>  error: parameter 'SizeOfTag' set but not used 
> [-Werror,-Wunused-but-set-parameter]
> void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, 
> cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>   
>  ^
> 2 errors generated.
> 
> 
> OS/X 12.4
> 
> 2.4 GHz Quad-Core Intel Core i5
> 
> If I should post that somewhere else let me know.
> 

Again fwiw, I commented out references to SizeOfTag in the two methods and got 
a good build.

./build/*/images/jdk/bin/jpackage --app-image 
~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
--mac-signing-key-user-name "Developer ID Application: Michael Hall 
(5X6BXQB3Q7)"
Bundler Mac DMG Package skipped because of a configuration problem: When using 
an external app image you must specify the app name. 
Advice to fix: Set the app name via the -name CLI flag, the 
fx:application/@name ANT attribute, or via the 'appName' bundler argument.

./build/*/images/jdk/bin/jpackage --app-image 
~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
--mac-signing-key-user-name "Developer ID Application: Michael Hall 
(5X6BXQB3Q7)" --name HalfPipe
Warning: Using unsigned app-image to build signed dmg.

*** The app-image was actually a signed one. I’m not sure that matters. Also 
since this would normally be my intention should there be a warning? ***

 codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its 
Designated Requirement

*** Seems successful ***

Thanks again.

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

[Michael Hall]

Fwiw, I was going to take a look at this but my build failed.

=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_liblcms_cmstypes.o:
/Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132:
 error: parameter 'SizeOfTag' set but not used 
[-Werror,-Wunused-but-set-parameter]
void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, 
cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)

   ^
/Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125:
 error: parameter 'SizeOfTag' set but not used 
[-Werror,-Wunused-but-set-parameter]
void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* 
io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)

^
2 errors generated.


OS/X 12.4

2.4 GHz Quad-Core Intel Core i5

If I should post that somewhere else let me know.

Re: RFR: 8286850: [macos] Add support for signing user provided app image

[Michael Hall]

Thank you.

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 19, 2022, at 7:14 PM, Michael Hall  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)

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

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

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 19, 2022, at 5:38 PM, Alexander Matveev  
> wrote:
> 
> Hi Michael,

Alexander

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

Thanks
Mike

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 11, 2022, at 4:39 PM, Alexander Matveev  
> wrote:
> 
> - It is not possible to support native JDK commands such as "java" inside Mac 
> App Store bundles due to embedded info.plist. Workarounds suggested in 
> JDK-8286122 does not seems to be visible.

I was just thinking about this. If you wanted a workaround to suggest to the 
user on the original issue. You could jar the native executables, extract them 
to a known accessible location, and then runtime them.

Having the commands jar’d would get them past the App Store check. Runtime on 
the client machine I doubt would object to the duplicate bundle id’s on 
absolute path execution but I haven’t double checked that. Also avoids issues 
with quarantine xattr’s. 
I’ve done something like this a couple times for interfacing an app to other 
languages. 

For example…

if (Files.exists(rscriptCmd)) {
isR = true;
System.out.println("InitialFinance: RScript 
available");
// Where is the finance data directory?
String data = prefs.get("data","N/A");

if (data.equals("N/A")) {
Application app = 
Application.getApplication();
Path documents = 
app.getFolder(DataTypes.DOCUMENTS);
dataLoc = 
Paths.get(documents.toString(),"finance");
}
else {
dataLoc = Paths.get(data);  

}
System.out.println("InitialFinance: data 
location is " + dataLoc);
Path resourceJar = 
Paths.get(System.getProperty("app.path"),"resource.jar");
System.out.println("InitialFinance: Checking 
resources for updates");
extractArchive(resourceJar,dataLoc);
}
else {
System.out.println("InitialFinance: " + 
rscriptCmd + " for " + initialRscript + " does not exist");
isR = false;
}

// 
https://stackoverflow.com/questions/1529611/how-to-write-a-java-program-which-can-extract-a-jar-file-and-store-its-data-in-s
public static void extractArchive(Path archiveFile, Path destPath) throws 
IOException {
Files.createDirectories(destPath); // create dest path folder(s)
try (ZipFile archive = new ZipFile(archiveFile.toFile())) {

@SuppressWarnings("unchecked")
Enumeration entries = (Enumeration) 
archive.entries();

// copy or create new or updated
while (entries.hasMoreElements()) {
ZipEntry entry = entries.nextElement();

if (!entry.getName().startsWith("finance/") || 
!(entry.getName().length() > 8)) {
continue;
}
String fileName = entry.getName().substring(8);
FileTime archiveTime = entry.getLastModifiedTime();

Path entryDest = destPath.resolve(fileName);
//if (Files.isDirectory(entryDest)) continue;
//Files.createDirectories(entryDest);
if (!Files.exists(entryDest)) {
Files.copy(archive.getInputStream(entry), 
entryDest, StandardCopyOption.REPLACE_EXISTING);   
continue;
}
BasicFileAttributes destAttr =
Files.readAttributes(entryDest, 
BasicFileAttributes.class);

if (archiveTime.compareTo(destAttr.creationTime()) > 0) {
Files.copy(archive.getInputStream(entry), entryDest, 
StandardCopyOption.REPLACE_EXISTING);  
}
}
}
catch (IOException ioex) {
throw ioex;
}
}

boolean debug = Boolean.getBoolean("R.debug");
rtexec(new String[] { RSCRIPT, 
script.toString() },debug);
 

Re: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 17, 2022, at 12:15 AM, Alexander Matveev 
>  wrote:
> 
> Hi Michael,
> 
> I filed following enhancement for signing user provided app image and yes it 
> will be two step process. Invoke jpackage to generate image, then user can 
> modified it and then invoke jpackage again to sign it.
> https://bugs.openjdk.java.net/browse/JDK-8286850
> 
> For JDK-8286122, I will integrate proposed fix as is. Error will be thrown if 
> user tries to include native commands for Mac App Store image.
> 
> Still not sure if we will provide solution for including native commands with 
> Mac App Store. Including special versions of native commands with jpackage 
> will work only if runtime is generated by jpackage. It will not solve issue 
> with user provided runtime. Also, it is not clear if app updates will require 
> same unique ID based on UUID across app versions.

This enhancement doesn’t directly concern this issue. Although given this 
enhancement it would be possible to provide a temporary ‘hack’ fix without 
building it into jpackage. Where the executables are changed to make them 
unique in the post-processing step. If it is not your intention to address this 
issue given this enhancement you would probably have to check the provided 
application bundle to be sure it doesn’t have the colliding Info.plist native 
commands. What Apple DTS provided may of had commands for this? I don’t 
remember. Or you would have to just fail any passed application bundles with 
native java commands.

From https://bugs.openjdk.java.net/browse/JDK-8286850 


> Generating DMG or PKG from —app-image with signing enabled will not sign app 
> image as it currently do.

I am not sure you would want to change this. If the developer doesn’t want to 
do any post-processing of the application bundle then they should be able to 
use the current invocations unchanged to do this?
I would think if you want post-processing you would generate unsigned 
applications, post-process, use the enhancement to sign. 


> 
> Also, many functionality provided by native JDK commands can be used via 
> ToolProvider. For example if you include jdk.jpackage module with your app, 
> you should able to use jpackage functionality from your app via ToolProvider 
> without actual jpackage native command.
> 
> Thanks,
> Alexander

Which might be another way this could be useful. If any 3rd parties want to 
generate their own application bundles they could still use jpackage as the 
definitive way to sign those.

Thanks 
Mike
> 

Re: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 16, 2022, at 7:09 PM, Alexander Matveev  
> wrote:
> 
> Hi Michael,
> 
>> 
 
 I’m not real familiar with the build process. But would it be possible for 
 the user to build their own jdk that substitutes something else for the 
 colliding identifier that gets embedded?
>>> Yes, it should be possible and in theory such JDK with native commands can 
>>> be used. However, current fix will not allow such JDK build, since we 
>>> checking for presence of “bin” folder and not if ID is actually unique. To 
>>> work around this limitation user can package without native commands first, 
>>> then add native commands and re-sign application.
>> 
>> Signing is currently an integrated part of the process. I thought about 
>> making an enhancement request to have it possible to do it stepped. First 
>> build the application, then allow the user to post-process that. Maybe run a 
>> tool/script to modify the application level Info.plist file. Then allow a 
>> second final step that does the signing. I don’t remember if I actually made 
>> that enhancement request. But currently there is no way with jpackage to 
>> standalone sign the application is there? I think this is somewhat involved 
>> with the application bundle being iterated and for one thing each jar being 
>> separately code signed? I think it took a release or two of the command to 
>> get this correct. So I doubt Xcode could manage it. Is there a way to do the 
>> signing standalone with jpackage that I am not aware of?
>> 
>> If I didn’t do an enhancement request on this I could, if you think jpackage 
>> could manage it?
>> 
> 
> There is no a way to do the signing of standalone app image and app image 
> will not get signed if you generating DMG or PKG by providing app image via 
> —app-image and specifing signing. Only PKG will get signed if signing is 
> specified with —app-image.
> 
> Currently jpackage will block following command:
> jpackage --type app-image --app-image Test.app --mac-sign ...
> Error: Option [--app-image] is not valid with type [app-image]
> 
> I think we can allow app-image type with app image input if signing is 
> requested and command from above will just sign app image in place.
> 
> Generating DMG or PKG from —app-image and with signing enabled will not sign 
> app image as it currently do.
> 
> If no objections for proposed enhancement I will go ahead and file one.
> 
> Thanks,
> Alexander

Alexander

I’m not entirely sure I’m following this. I assumed it wasn’t currently 
possible to do standalone signing against an application bundle but would 
require an enhancement request. If you are saying you will do that request 
yourself, that’s fine.
Again, I think this should be possible as a two step process. The first would 
be to generate the application bundle. Then perform some application bundle 
post-processing, probably independent of jpackage. Finally allow a jpackage 
invocation that takes the path to the completed application bundle and performs 
the signing. 
If this is what you are thinking we are on the same page. 

Thanks
Mike

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

[Michael Hall]

> On May 12, 2022, at 3:13 PM, Magnus Ihse Bursie  wrote:
> 
> On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev  
> wrote:
> 
>>> - It is not possible to support native JDK commands such as "java" inside 
>>> Mac App Store bundles due to embedded info.plist. Workarounds suggested in 
>>> JDK-8286122 does not seems to be visible.
>>> - With proposed fix we will enforce "--strip-native-commands" option for 
>>> jlink, so native JDK commands are not included when generating Mac App 
>>> Store bundles.
>>> - Custom runtime provided via --runtime-image should not contain native 
>>> commands as well, otherwise jpackage will throw error.
>>> - Added two tests to validate fix.
>> 
>> Alexander Matveev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>  8286122: [macos]: App bundle cannot upload to Mac App Store due to 
>> info.plist embedded in java exe [v2]
> 
> We have the `NSMicrophoneUsageDescription` permission on the `java` launcher 
> in the JDK, since otherwise no Java program can access the mike, even though 
> most won't care. I agree that the situation is different for a jpackaged app, 
> where the developer knows if that permission is needed or not.

I’d have to agree with Apple DTS that this is an interesting exception. 

> 
> Yes, plistbuddy is an official Apple program.
> 
> My understanding of the PR was that native commands are removed by jlink if 
> the user is packaging on a mac for the App Store. I thought this was a 
> workaround that solved the immediate problem of not being able to submit the 
> app to App Store. (However, I don't know how the app is supposed to be 
> started without a launcher…)
> 

I thought that if the app was indicated as intended for the App Store and 
native commands were also indicated an error would be thrown and the app not 
built. It doesn’t allow apps that will fail to attempt the App Store but does 
nothing for getting them there. Switching from an error to a warning and 
forcing the native commands to be stripped would allow the app into the app 
store but with unknown functionality probably not working. My understanding. 

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> 
> My primary suggestion would to be to use an UUID for the unique ID. They are 
> of fixed length, are for all intents and purposes unique and you can conjure 
> them up from your hat. (An alternative is that the user needs to specify a 
> unique ID, but that is probably a less ideal solution.) Presumably, we can 
> have some kind of prefix like "org.openjdk.jpackage." before the UUID to make 
> them a bit understandable, if someone where to inspect the package metadata.e 

I was thinking jpackage would change the XXX to app name but a fixed size 
unique field would probably be better.
> 
> This seems like a fully workable solution to me. However, I'd really like to 
> understand option #1 better, which was: "Package the `java` executable in a 
> standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink to 
> that."
> 
> I don't know what a "standard bundle" is, or how you would go around to 
> package the java executable in one. But on the surface, it sounds much nicer 
> than binary editing.
> 
> I also don't understand if that means that the standard bundle needs to be 
> created at jpackage time, so it gives us the chance to set a proper ID, or if 
> the standard bundle can be created at build time, and then the existence of 
> this bundle just makes Apple avoid the bundle ID collision checks. Or if I'm 
> just misunderstanding it all...
> 
> /Magnus

I may again not understanding but I was thinking they were talking about 
something like symlinks to a machine installed JDK and this seemed to me to 
defeat some of the purpose of embedding the jdk. But he could be thinking else. 
Something external to the application anyhow it seemed.

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 12, 2022, at 4:42 AM, Magnus Ihse Bursie 
>  wrote:
> 
>> Some further spelunking reveals the issue. Consider this: 
>> 
>> % otool -s __TEXT __info_plist -v 
>> APP_NAME.app/Contents/runtime/Contents/Home/bin/java 
>> … 
>>  
>> CFBundleIdentifier 
>> net.java.openjdk.java 
>> … 
>>  
>>  
>> 
>> This is an obscure corner case in the macOS bundle story: A standalone tool, 
>> like `java`, which isn’t in a bundle structure, and thus can’t have a 
>> standalone `Info.plist` file, can put its information property list in a 
>> `__TEXT` / `__info_plist` section within its executable. And it seems that 
>> the folks who created your Java runtime did just that. 
>> 
>> Given that, the Mac App Store error is valid: You are trying to submit an 
>> executable whose bundle ID matches some existing app. 
>> 
>> To get around this check you’ll need to give `java` a new bundle ID. That’s 
>> not easy to do. This `__TEXT` / `__info_plist` section is set up by a linker 
>> option (see `-sectcreate` in  
>> and there’s no good way to modify it after the fact [1]. 

I had read this but possibly didn’t grok the issue myself. If I understand 
correctly now the conflict isn’t within the application but across applications 
to some other application that has already been added to the Mac App Store that 
included the commands with the given CFBundleIdentifier. A solution like 
including a bundle identifier something like net.java.openjdk.MYAPP.java would 
be possible at packaging time but not at build time. 
To fix this at build time you would need to generate a name unique to each 
installed jdk. Including release net.java.openjdk.JDK_RELEASE.java might avoid 
some conflicts but would still be open to conflict for two applications at the 
same release. So it can’t be addressed ‘before the fact’ either. The only thing 
I am currently thinking of that might work would be include a replaceable part 
in the identifier. So something like 
net.java.openjdk.java.XX
Where jpackage could include something to change the X…. to a unique 
application name. If you don’t change the string size you could probably avoid 
some of the resizing issues Apple DTS mentions. Whether there is a standard 
Apple tool to do this I don’t know. 

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

Alexander

> On May 11, 2022, at 11:38 PM, Alexander Matveev 
>  wrote:
> 
> Hi Michael,
> 
>> On May 11, 2022, at 3:17 PM, Michael Hall  wrote:
>> 
>> Is this restricted somehow to Mac App Store applications?
> Yes, helper tools (in our case JDK native commands) in Mac App Store 
> applications cannot use same bundle ID as another application. Since we have 
> bundle ID embedded in native commands multiple applications cannot use it 
> without updating each native command with unique bundle ID and since they 
> embedded inside executable I do not see how it would be possible to change 
> during packaging.

Possibly not during packaging but during the jdk build of the native commands? 
Somehow the Info.plist must be getting embedded and a bundle id provided. I’m 
not sure where or how. But one way to get uniqueness if the id is provided to 
embed the Info.plist in the native command executable compile/link  would be to 
include the command as part of the identifier. Something like CFBundleID = 
java.native.cmd or CFBundleID = javac.native.cmd. 

>> 
>> Is a warning issued as stripping native commands  may break application 
>> functionality?
> No, error will be issues and jpackage will exit with error if —mac-app-store 
> arguments is used and provided runtime has native tools or user did not 
> specified --strip-native-commands to jlink.

A warning might be sufficient if the commands are included accidentally by the 
user unintentionally omitting the —strip-native-commands with the jlink 
options. Then just force the —strip-native-commands option. It might be the 
application will just lose some non-critical functionality even if they meant 
to have the native command included.

>> Is it not possible for the user to provide their own Info.plist with  a 
>> different bundle identifier that doesn’t collide?
> Not possible due to native commands have embedded Info.plist.

Maybe I’m misunderstanding the conflict. Are the commands conflicting with the 
application level Info.plist or with each other? I believe jpackage usually has 
a mechanism where a substitute Info.plist can be used if the conflict is with 
the application level. If multiple commands are conflicting with each other 
this won’t work.

>> 
>> I’m not real familiar with the build process. But would it be possible for 
>> the user to build their own jdk that substitutes something else for the 
>> colliding identifier that gets embedded?
> Yes, it should be possible and in theory such JDK with native commands can be 
> used. However, current fix will not allow such JDK build, since we checking 
> for presence of “bin” folder and not if ID is actually unique. To work around 
> this limitation user can package without native commands first, then add 
> native commands and re-sign application.

Signing is currently an integrated part of the process. I thought about making 
an enhancement request to have it possible to do it stepped. First build the 
application, then allow the user to post-process that. Maybe run a tool/script 
to modify the application level Info.plist file. Then allow a second final step 
that does the signing. I don’t remember if I actually made that enhancement 
request. But currently there is no way with jpackage to standalone sign the 
application is there? I think this is somewhat involved with the application 
bundle being iterated and for one thing each jar being separately code signed? 
I think it took a release or two of the command to get this correct. So I doubt 
Xcode could manage it. Is there a way to do the signing standalone with 
jpackage that I am not aware of?

If I didn’t do an enhancement request on this I could, if you think jpackage 
could manage it?
 
> 
>> Or just change it in the current build so it doesn’t collide? With the 
>> application or whatever one it is colliding with.
> Not possible, since ID should be unique per application.

Possibly you are misunderstanding me here I think you already indicated the 
could be done ‘in theory’. It still seems possibly the correct ‘fix’. Change 
the build so uniqueness is not an issue.
> 
> Thanks,
> Alexander

Thanks,
Mike

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 11, 2022, at 5:17 PM, Michael Hall  wrote:
> 
> I’m not real familiar with the build process. But would it be possible for 
> the user to build their own jdk that substitutes something else for the 
> colliding identifier that gets embedded?

Or just change it in the current build so it doesn’t collide? With the 
application or whatever one it is colliding with.

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

Is this restricted somehow to Mac App Store applications?

Is a warning issued as stripping native commands  may break application 
functionality?

Is it not possible for the user to provide their own Info.plist with  a 
different bundle identifier that doesn’t collide?

I’m not real familiar with the build process. But would it be possible for the 
user to build their own jdk that substitutes something else for the colliding 
identifier that gets embedded?

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

[Michael Hall]

> On Nov 29, 2021, at 1:14 PM, Mandy Chung  wrote:
> 
> On Wed, 24 Nov 2021 12:32:32 GMT, Michael Hall  wrote:
> 
>> Would there be any need to scan class path at all? That would mean a module 
>> would have a class path dependency wouldn't it?
> 
> One reason of scanning the class path is to detect any split packages and 
> emit warnings.   
> 
>> Yes, I shouldn't of included -cp at all but shouldn't keeps ignore it?
> 
> In general, a module should not depend on any class on the classpath.   
> However, it's possible that there is any missing dependency i.e. can't be 
> found from its required modules.   One could use `-cp` to add additional 
> libraries for a quick analysis.
> 
> I got your point though.   Scanning class path is not strictly necessary to 
> analyze dependencies and it can be done lazily.   Finding all packages in the 
> unnamed module is just the current implementation.  I'll consider and look 
> into making it lazy.
> 
> -
> 
> PR: https://git.openjdk.java.net/jdk/pull/6531

Sorry,
Didn’t see this.

Thanks for the reply. 

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

[Michael Hall]

> On Nov 24, 2021, at 5:51 AM, Michael Hall  wrote:
> 
> 
> 
>> On Nov 24, 2021, at 2:55 AM, Alan Bateman  wrote:
>> 
>> On Wed, 24 Nov 2021 01:12:01 GMT, Mandy Chung  wrote:
>> 
>>> This changes jdeps -cp to ignore files/directories with no permission to 
>>> access.  This is consistent with the runtime behavior.
>> 
>> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 
>> 235:
>> 
>>> 233: @Override
>>> 234: public FileVisitResult visitFileFailed(Path file, 
>>> IOException exc) throws IOException {
>>> 235: return FileVisitResult.CONTINUE;
>> 
>> The bug report may be pilot error in that they seem to have specified a root 
>> directory as the class path. If the scan is changed then maybe it should 
>> minimally emit a warning rather than silently ignoring the non-accessible 
>> files.
>> 
>> -
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/6531
> 
> This was testing against a simple unpackaged class in my home directory. All 
> the dependencies were javafx modular ones.
> There was definitely no dependency on a /Pictures package where there would 
> be any need to look any further on this path.
> Is this scanning every directory off a class path one on the chance there 
> might be a java class file that is a dependency?
> 
Given this invocation
jdeps --module-path ~/Documents/javafx-sdk-17.0.1/lib --print-module-deps -cp . 
PushMe.class 

Would there be any need to scan class path at all? That would mean a module 
would have a class path dependency wouldn’t it? Is that possible? 
Yes, I shouldn’t of included -cp at all but shouldn’t jeeps ignore it?

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

[Michael Hall]

> On Nov 24, 2021, at 2:55 AM, Alan Bateman  wrote:
> 
> On Wed, 24 Nov 2021 01:12:01 GMT, Mandy Chung  wrote:
> 
>> This changes jdeps -cp to ignore files/directories with no permission to 
>> access.  This is consistent with the runtime behavior.
> 
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 235:
> 
>> 233: @Override
>> 234: public FileVisitResult visitFileFailed(Path file, 
>> IOException exc) throws IOException {
>> 235: return FileVisitResult.CONTINUE;
> 
> The bug report may be pilot error in that they seem to have specified a root 
> directory as the class path. If the scan is changed then maybe it should 
> minimally emit a warning rather than silently ignoring the non-accessible 
> files.
> 
> -
> 
> PR: https://git.openjdk.java.net/jdk/pull/6531

This was testing against a simple unpackaged class in my home directory. All 
the dependencies were javafx modular ones.
There was definitely no dependency on a /Pictures package where there would be 
any need to look any further on this path.
Is this scanning every directory off a class path one on the chance there might 
be a java class file that is a dependency?

Re: RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

[Michael Hall]

> On Nov 23, 2021, at 7:19 PM, Mandy Chung  wrote:
> 
> This changes jdeps -cp to ignore files/directories with no permission to 
> access.  This is consistent with the runtime behavior.
> 
> -
> 
> Commit messages:
> - JDK-8277375: jdeps errors on a class path with a file path with no 
> permission
> 
> Changes: https://git.openjdk.java.net/jdk/pull/6531/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6531=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8277375
>  Stats: 113 lines in 2 files changed: 106 ins; 0 del; 7 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/6531.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6531/head:pull/6531
> 
> PR: https://git.openjdk.java.net/jdk/pull/6531

For JDK-8277375 with -cp .
Given the error…
Exception in thread "main" java.io.UncheckedIOException: 
java.nio.file.FileSystemException: ./Pictures/Photos Library.photoslibrary: 
Operation not permitted

Doesn’t this indicate a recursed directory is being checked. This shouldn’t 
happen should it? Classpath is given as current directory only.

Also in this case it turns out the class in question I believe has no class 
path dependencies, possibly not directly related to the bug, but shouldn’t be 
possible to determine there is no need to scan class path at all to resolve 
anything? Maybe not.

Re: [External] : Re: jpackage - notarizing

[Michael Hall]

> On Nov 22, 2021, at 9:01 PM, Kevin Rushforth  
> wrote:
> 
> By way of clarification, JNF was never part of the JDK. What we removed was 
> the JDK's *usage* of JNF. And we did so because Apple deprecated it and never 
> even provide a JNF framework for aarch64.
> 
> Applications either need to migrate off JNF and find an alternative, or take 
> Apple's open-source project, build it yourself, and include it with your 
> application. Either way, this isn't a JDK problem.
> 
> — Kevin

None of what Apple contributed to the Mac port project was part of the JDK. But 
legacy Apple Java code still used it. Probably less over time, allowing it to 
be phased out. All I was thinking of was somewhere it would still be available 
to compile old code. What Alan pointed out would probably provide that if Apple 
stops including it with Xcode - if I figure it out. If you look at the GitHub 
project the contributors include people you still see active on the openjdk 
lists. All I basically need is it there to compile old code I don’t actively 
develop. 

Alan’s usage sounded a little more critical.

Re: jpackage - notarizing

[Michael Hall]

> On Nov 22, 2021, at 12:39 PM, Alan Snyder  wrote:
> 
> 
>> On Nov 22, 2021, at 10:12 AM, Kevin Rushforth  
>> wrote:
>> 
>> JNF was removed from the JDK if that's what you are asking.
> 
> 
> 
> Indeed, that is why there is an issue.
> 
> The JDK may not be using JNF, but library developers still use it.
> 
> The JDK replacement for JNF is not supported for use outside the JDK.
> 
> JNF is not just convenient, there is at least one essential use for which 
> there is no adequate replacement.
> 
> See https://bugs.openjdk.java.net/browse/JDK-8274596
> 
> 
> 
I have a fair amount of code that would break if some JNF option wasn’t 
available. I have no estimate for how much rewriting I would need to do. Two of 
the projects I needed to recompile to get notarized needed it. I don’t actively 
do anything with it anymore but have some older code that did.

Re: jpackage - notarizing

[Michael Hall]

> On Nov 22, 2021, at 11:59 AM, Alan Snyder  wrote:
> 
> I’m talking about the Xcode project for JNF.
> 

I thought I was too. Unless it’s changed since I cloned or the one I’m looking 
at is somehow different. The URL I saved was  https://github.com/apple/openjdk/ 
 which looks to build JNF. Not that much a 
concern as of yet if the SDK still has it.

Thanks again.

Re: jpackage - notarizing

[Michael Hall]

> On Nov 22, 2021, at 11:44 AM, Alan Snyder  wrote:
> 
> JNF is just an Objective-C library that uses jni.h. Otherwise, it is not 
> dependent on the JDK.
> 
>> On Nov 22, 2021, at 9:23 AM, Michael Hall  wrote:
>> 
>> 
>> 
>>> On Nov 22, 2021, at 10:40 AM, Alan Snyder  wrote:
>>> 
>>> I’m still hoping someone will step up to provide a home for the compiled 
>>> JavaNativeFoundation framework.
>>> 
>>> In any case, the sources are available and you can build it yourself.
>>> 
>>> https://github.com/apple/openjdk.git <https://github.com/apple/openjdk.git>
>> I had found this one as well.  It included an Xcode project and seemed to be 
>> around jdk14? 
>> I didn’t figure out what to do with it but it seemed like it might have a 
>> limited shelf life too where it will work without a fair amount of effort.
>> 
>> Thanks.
> 

I had cloned it and just saw this
openjdk-xcodejdk14-release

The Xcode project doesn’t appear to include any java version dependencies.
There is this…
HEADER_SEARCH_PATHS = $(SRCROOT)/../../src/java.base/share/native/include 
$(SRCROOT)/../../src/java.base/unix/native/include

But I’m not sure where that’s really pointing. I usually do command line.

Re: jpackage - notarizing

[Michael Hall]

> On Nov 22, 2021, at 10:40 AM, Alan Snyder  wrote:
> 
> I’m still hoping someone will step up to provide a home for the compiled 
> JavaNativeFoundation framework.
> 
> In any case, the sources are available and you can build it yourself.
> 
> https://github.com/apple/openjdk.git 
I had found this one as well.  It included an Xcode project and seemed to be 
around jdk14? 
I didn’t figure out what to do with it but it seemed like it might have a 
limited shelf life too where it will work without a fair amount of effort.

Thanks.

jpackage - notarizing

[Michael Hall]

While I was looking at —mac-dmg-content I thought I would also look at 
notarization. I had downloaded my app on an older machine while my new was 
being serviced and got uninviting messages about Apple being unable to 
determine it was full of malware. Notarization I found out was supposed to be 
the way to eliminate these messages. 

I did manage notarization eventually using Mac/Xcode command line tools. 

Am I duplicating anything jpackage would do for me somehow? Some option I’m not 
aware of? 

I did have to recompile some code because binaries were before the 10.9 SDK.

This had the issue where I have to include
SDK_ROOT="$(xcrun --show-sdk-path)”
gcc … 
-I${SDK_ROOT}/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/Headers...-F${SDK_ROOT}/System/Library/Frameworks/JavaVM.framework/Frameworks

In order to use JavaNativeFoundation. Is there nothing that can be done about 
JavaNativeFoundation code breaking when Apple decides not to include it in the 
Xcode SDK’s?

Also, again I think an Apple issue, but if someone else runs into it. I 
currently seemed to be in some kind of command line tool (CLT) limbo in 
compiling. I was getting AppKit errors. Google showed others having this 
problem where using Xcode itself instead of the CLT was the solution. I have 
not used Xcode for JNI, it didn’t seem well suited. This appeared to be some 
problem where my OS/X 10.15 Catalina version is getting a little dated, 
including with my Xcode 12.4 version.

I was unable to figure out how to CLT compile on my current machine but was 
able to on my older Mac.

Again I assume this is an Apple thing. 

Notarization was finally successful though.

Re: jpackage --mac-dmg-content

[Michael Hall]

Nit, if you open the dmg the additional content doesn’t quite fit in the bottom 
of the window.

My thought had been smaller icons for the additional. This doesn’t seem 
possible?

jpackage --mac-dmg-content

[Michael Hall]

[08:26:41.669] jdk.jpackage.internal.PackagerException: Error: Option 
[--mac-dmg-content] is not valid with type [default]

dmg is the default type? Why should this be an error?

Re: RFR: JDK-8263155: Allow additional contents for DMG

[Michael Hall]

> On Oct 14, 2021, at 5:12 PM, Andy Herrick  wrote:
> 
> On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick  wrote:
> 
>> JDK-8263155: Allow additional contents for DMG
> 
> This enhancement adds a command line option "--mac-dmg-content" that can be 
> used to add any other content to a dmg image.  The default DMGsetup.scpt  is 
> modified to show all the additional content on a second row in Finder (under 
> the application or java runtime and it's install directory).
> Changes only ap[ply to dmg type bundles
> 
> -
> 
> PR: https://git.openjdk.java.net/jdk/pull/5912

+1

Re: JPackage and ask for microphone permissions broken on OSX...

[Michael Hall]

> On Aug 25, 2021, at 8:40 AM, Alan Snyder  wrote:
> 
> 
> 
>> On Aug 24, 2021, at 6:52 AM, Andy Herrick  wrote:
>> 
>> One final thing to note, MacOS keeps track of what you have ever previously 
>> granted microphone permission to (and will never ask again) based on the mac 
>> package identifier (which defaults to the main class name), so I explicitly 
>> set this using a shell script with jpackage option "--mac-package-identifier 
>> audio-$1" option, so I can pass in different values and create a unique one 
>> each time.
> 
> I’ve been wondering what you mean here.
> 
> Are you saying that you routinely generate random package identifiers or is 
> this a workaround that you use in special circumstances?
> 
>  Alan
> 

I believe the permission is granted to a bundle idenditifer. I think tccutil 
can be used to reset

https://apple.stackexchange.com/questions/384317/how-do-i-reset-camera-and-microphone-permission-on-macos-mojave
 

Re: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out

[Michael Hall]

> On Jul 22, 2021, at 1:46 PM, Alexey Semenyuk  
> wrote:
> 
> Oh, inconsistent path separators indeed. Good catch! This is the reason it 
> doesn't work as it should.
> Filed https://bugs.openjdk.java.net/browse/JDK-8271155 to track it.
> 
> - Alexey
> 
> 

Thank you.

Re: jpackage OS/X JDK-8263157 fix regressed out

[Michael Hall]

> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk  
> wrote:
> 
> The fix for JDK-8263157 cleared the default value of `java.library.path` 
> system property and resulted in JDK-8267598 regression. So the fix for 
> JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system 
> property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env variable on 
> OSX. OSX JVM startup code builds the value of `java.library.path` system 
> property from the value of `DYLD_LIBRARY_PATH` env variable. This way 
> jpackage doesn't interfere with the default JVM initialization code and also 
> adds `app`  directory to `java.library.path` system property.
> As far as I can see it from the log, the value of `java.library.path` 
> contains `app` dir - 
> `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So 
> it works as expected.
> Are you sure the native library is in place?
> 
> - Alexey
> 

I missed that it was there somehow, but…

ls outputdir/HalfPipe.app/Contents/app | grep dylib
libAppleScriptEngine.dylib
libBSF4ooRexx.dylib
libfscript.dylib
libhp.dylib
libmacattrs.dylib

Also overriding 
-Djava.library.path=$APPDIR
worked. So I didn’t look too closely. 
So what am I still missing?
;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
Inconsistent path separators?

jpackage OS/X JDK-8263157 fix regressed out

[Michael Hall]

JDK-8263157  [macos]: 
java.library.path is being set incorrectly

The fix for this seems to be gone in both current jdk17 and jdk18 releases. 
There is no ‘app’ directory included in java.library.path.

outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java -version
openjdk version "18-ea" 2022-03-15
OpenJDK Runtime Environment (build 18-ea+6-237)
OpenJDK 64-Bit Server VM (build 18-ea+6-237, mixed mode)

outputdir/HalfPipe.app/Contents/MacOS/HalfPipe
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in 
java.library.path: 
/opt/ooRexx/lib/ooRexx;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
at java.base/java.lang.System.loadLibrary(Unknown Source)
at us.hall.hp.common.LoaderLaunchStub.(LoaderLaunchStub.java:35)
Failed to launch JVM

Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

[Michael Hall]

> On Jul 21, 2021, at 3:57 PM, Andy Herrick  wrote:
> 
> Looks like an instance of: JDK-8260335 
>  : [macos] Running app 
> using relative path causes problems (fixed in jdk17 build b09)
> 
> you can try builds from https://jdk.java.net/17/ to confirm fix.
> 
> /Andy
> 
> On 7/21/2021 4:46 PM, Bruno Borges wrote:
>> Hi all,
>> 
>> Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and 
>> the generated app-image comes with a binary launcher that tries to load the 
>> .cfg file from the wrong directory.
>> 
>> 
>> ├── PkgInfo

Somewhat off-topic. I hadn't noticed that PkgInfo was included on my 
applications? It used to have creator/type OSType’s needed for AppleEvent’s to 
work properly but since creator/type are pretty much out of use I thought 
PkgInfo was too?

Re: jpackage GraalVM on Windows 10

[Michael Hall]

> On May 20, 2021, at 6:45 PM, Michael Hall  wrote:
> 
> Has anyone done this who can indicate how it should be done?
> 

It seems to be the non-standard JDK name. I renamed it to jdk-11 and it worked. 
Letting it default still set it to the current jdk-16 even though that was 
later in PATH.
But using —runtime-image worked.
I’ll bug report if non-standard JDK names can be expected to be supported.

jpackage GraalVM on Windows 10

[Michael Hall]

Has anyone done this who can indicate how it should be done?

I recently set this up for my app on OS/X and thought I’d have cross platform 
versions.
I have tried it both with —runtime-image and making Graal the installed JVM.

Both ways I seem to get an application with directory structure

runtime
—— graalvm-ce-java11-21.1.0
—bin
—conf
…

It appears it should not have the Graal dir in there. I removed it and the 
application runs. Otherwise no.
Again it seems to do this even if I let it default to the installed Graal jdk - 
not —runtime-image.

If no one else has run into this and figured something out or just knows how to 
do it correctly I can just do a bug report.

Re: jpackage java commands

[Michael Hall]

> On May 19, 2021, at 9:40 AM, Andy Herrick  wrote:
> 
> I don't think jlink will ever include the jdk development tools in a custom 
> runtime (using jlink on windows or mac without --strip-native-commands only 
> gives me java and keytool),

Mac gave me the 9 commands shown earlier. Something inconsistent involved?

> but you can include the whole jdk (less src.zip and the jmods directory) by 
> using --runtime-image  and pointing  to the JDK you 
> are running jpackage from (or you can take copy of that JDK, modify it in any 
> way you want, and point to that)).

I was trying a couple of these options for something unrelated last night. Just 
a quick look not extensive. But it seemed like if you copy —runtime-image you 
are limited in making some modular changes to that runtime. I also tried 
directly using jlink to make the runtime myself but that also errored. I didn’t 
make any effort to figure out the problem at that time. A linkage error of some 
sort in class initialization for my launcher class. 
Manually changing a copied runtime I didn’t try. You could then just copy the 
commands you need to the jpackage runtime if the application is unsigned? I 
used to do something similar for app’s that needed an embedded ‘java’ command 
available. But got scolded for doing so when I mentioned it on this list. 

If the functionality is critical to the app I will probably have to make one of 
those options work. Currently it isn’t critical. So I guess I could just add an 
availability check.

Thanks.

jpackage java commands

[Michael Hall]

I added 
--jlink-options '--strip-debug --no-man-pages --no-header-files’
to my invocation, avoiding --strip-native-commands,  so that the native java 
commands are not stripped. I believe currently recommended jpackage way to do 
this.
I get the following commands in my embedded JDK

javajdb jshell  rmidserialver
javac   jrunscript  keytool rmiregistry

The installed jdk bin directory has 29 different commands including ones like 
jpackage, jlink, javap, jcmd…

What if I want to run one of those from the application? I can exec them but 
the version might not match the embedded?

Not a current problem that I know of, I will use the installed for now.

  

Re: Jpackage Mac entitlements

[Michael Hall]

> On Apr 22, 2021, at 7:41 AM, Andy Herrick  wrote:
> 
> 
> On 4/21/2021 6:15 PM, Michael Hall wrote:
>> Reverted to Jdk 16 and temporarily couldn’t figure out why AppleScript 
>> wasn’t working again.
>> 
>> I needed to provide an entitlement. At jpackage 16 I found I needed to do 
>> this differently with a .entitlements file in the resources 
>> directory, as I noticed in the verbose command output.
>> 
>> I had previously noticed that jpackage 17 now includes a parameter to 
>> provide this.
>> 
>> Will both options continue to be supported, resource dir and parm, or will 
>> parm become the only supported way at or after 17?
> 
> Yes, if --mac-entitlement options exists, it will use it, otherwise , the 
> previous behavior is maintained, the default resource entitlements.plist in 
> the source code will be used unless overridden by .entitlements in 
> the resource directory.
> 
> /Andy
> 

Ok so in order…

—mac-entitlement
.entitlements
jpackage provided default

If at some point after the —mac-entitlement parameter has been in place for a 
while and it is decided to eliminate the resource dir option a warning message 
might be an idea.

I still think possibly including a verify error exception or warning might also 
be helpful if that has issues

I figured out that when I was trying different things with signing I must of 
deleted my Developer ID Application: certificate from keychain. Which is what 
must of been being found by the jpackage /usr/bin/security find-certificate. 
Hard coding my fully qualified “3rd Party” cert was working fine.

After putting my Developer ID Application cert back in the keychain signing 
again worked by just using my name - but once more the app doesn’t verify. 
This time if I codesign -v it seems ok. But for some reason the Taccy 
application shows…

App signature check:
⛔️ spctl error 3
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: 

For what I am doing this is not a problem but could be a concern for someone 
trying to get an application into the App Store. 

So, if you do not currently have plans to do something or there is already a 
RFE in place that you know of. I will submit one to include a verify on signed 
applications.

Jpackage Mac entitlements

[Michael Hall]

Reverted to Jdk 16 and temporarily couldn’t figure out why AppleScript wasn’t 
working again.

I needed to provide an entitlement. At jpackage 16 I found I needed to do this 
differently with a .entitlements file in the resources directory, as 
I noticed in the verbose command output.

I had previously noticed that jpackage 17 now includes a parameter to provide 
this. 

Will both options continue to be supported, resource dir and parm, or will parm 
become the only supported way at or after 17?

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 9:37 AM, Michael Hall  wrote:
> 
> So apparently ‘cp’ is not a good idea on a signed application. At least not 
> on a signed java one. 

Fyi for anyone who wants to copy a Mac signed java app from a script or maybe 
from java Runtime. Instead of…

cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app

this…

ditto /Volumes/HalfPipe outputdir

Copies and still codesign verifies.

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 9:14 AM, Michael Hall  wrote:
> 
>> only executables and libraries are signed - this tool running across the 
>> whole app will find unsigned files, that would be expected.
> 
> Hmm. ok. Is the jdk separately signed? Would something in copying it change a 
> date or something that would cause the verify to fail on the jdk signature 
> thinking something has changed rather than what you sign for the app?
> 
> ls -l HalfPipe.app/Contents/runtime/Contents
> total 8
> ...
> drwxr-xr-x  3 mjh  staff   96 Apr 16 19:29 _CodeSignature

OK I think this may be it. For my testing I sort of force the DMG build back to 
the —install-dir one.

open -Wg HalfPipe-1.0.dmg
cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app
…
diskutil eject HalfPipe
open outputdir/HalfPipe.app

codesign -v outputdir/HalfPipe.app
outputdir/HalfPipe.app: a sealed resource is missing or invalid

If instead I do the proper drag and drop install to the Applications directory.
codesign -v /Applications/HalfPipe.app

No error. So apparently ‘cp’ is not a good idea on a signed application. At 
least not on a signed java one. 

This one can probably be closed permanently.

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 9:14 AM, Michael Hall  wrote:
> 
>>>> 
>>>> With —install-dir this remains a reproducible bug for me at 17-ea.
>> yes - but what is value of "--install-dir" - can you insure it is a fully 
>> qualified directory path that exists on all users machines and all users 
>> have write access to ?  With the current code, if applescript cannot create 
>> alias to this location on target machine it will show this buggy looklin 
>> gfinder view.
>>>> 
>>>> If a reference build was provided somewhere I might have picked up on the 
>>>> parameter difference sooner.
>>>> 
>>>> 
>> /Andy
> 
> Yes, there is no good reason to do this and my doing it was a mistake. But 
> currently still at 17ea

Sorry got distracted thinking about the signature thing.
But currently at 17ea if a user, other than myself now, makes the same mistake 
of including —install-dir the DMG problem is still there.

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 8:57 AM, Andy Herrick  wrote:
> 
> 
> On 4/17/2021 1:14 AM, David Holmes wrote:
>> Hi Michael,
>> 
>> On 17/04/2021 10:57 am, Michael Hall wrote:
>>> Is there anyway to get a simple/test reference type application available 
>>> that could be used in reproducing bugs?
> I put a simple test application I was using in your bug report: 
> https://bugs.openjdk.java.net/browse/JDK-8263156 
> <https://bugs.openjdk.java.net/browse/JDK-8263156>

I’ll start with this or at least take a look at it in attempting a reproducer.

>>> 
>>> I had two I think potentially serious bugs that were basically not 
>>> addressed for problems in reproducing.
>>> 
>>> JDK-8263156 : [macos]: OS X application signing concerns - a sealed 
>>> resource is missing or invalid
>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156> 
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>>
>>> 
>>> The command to reproduce was provided. The error appears to be in files 
>>> included in the embedded JDK not being signed. So apparently not having to 
>>> do with anything of mine. (Mentioned I now see in the comments).
> 
> only executables and libraries are signed - this tool running across the 
> whole app will find unsigned files, that would be expected.

Hmm. ok. Is the jdk separately signed? Would something in copying it change a 
date or something that would cause the verify to fail on the jdk signature 
thinking something has changed rather than what you sign for the app?

ls -l HalfPipe.app/Contents/runtime/Contents
total 8
...
drwxr-xr-x  3 mjh  staff   96 Apr 16 19:29 _CodeSignature

> 
>>> 
>>> As I indicate this is not a serious error for me since I am not submitting 
>>> the app to the Mac App Store but I believe this would get the app Apple 
>>> rejected for anyone who is attempting that. A show stopper for a major use 
>>> case. It seems too bad to simply close it because I missed an email asking 
>>> for a reproduce.
>> 
>> Note the bug referenced is closed as "incomplete" - that is a temporary 
>> state while awaiting additional information  (usually from the submitter). 
>> If we never hear back from the submitter then it will be closed with a 
>> different (more terminal) state. If we do hear back then the bug gets 
>> reopened.
>> 
>> Cheers,
>> David
>> 
>>> With a reference application I could demonstrate the error against would 
>>> eliminate the need to provide a separate reproducible test case. Quite 
>>> sized for the application in question. Such an application is actually 
>>> mentioned in the bug report comments. Could such a application be made 
>>> available for download or user reproducing - the jpackage command and 
>>> arguments?
>>> 
>>> I have looked a little bit at if to see if I can figure out how to sign the 
>>> embedded jdk files. So far only accomplishing that I can no longer simply 
>>> use my name for signing but have to use my fully qualified security 
>>> identity.
>>> 
>>> The question now seems to be what is in fact the difference between mine 
>>> and the, unavailable to me, reference application as to these files 
>>> verifying as correctly signed.
>>> 
>>> A second bug
>>> JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect
>>> 
>>> I thought a fix for this was all set to go in and was pulled. It was 
>>> apparently determined that the problem only applies if the —install-dir 
>>> parameter is used for DMG’s. Where it really makes no sense. My use 
>>> apparently held over from when I was just creating the app.I thought this 
>>> had somehow also in some way regressed to not reproducible. I still think a 
>>> fairly simple change to the AppleScript as was originally planned would 
>>> resolve the issue independently of parameters. The default DMG build I 
>>> would think should _always_ indicate installation to the Applications 
>>> folder.
> 
> This is the change proposed now by Alexander on pull request: 
> https://git.openjdk.java.net/jdk/pull/3505 
> <https://git.openjdk.java.net/jdk/pull/3505>
> 
> That  dmg should ignore --input-dir and always propose dragging apps into 
> /Applications

Agreed.

> 
>>> 
>>> With —install-dir this remains a reproducible bug for me at 17-ea.
> yes - but what is value of "--install-dir" - can you insure it is a fully 
> qualified directory path that exists on all users machines and all users have 
> write access to ?  With the current code, if applescript cannot create alias 
> to this location on target machine it will show this buggy looklin gfinder 
> view.
>>> 
>>> If a reference build was provided somewhere I might have picked up on the 
>>> parameter difference sooner.
>>> 
>>> 
> /Andy

Yes, there is no good reason to do this and my doing it was a mistake. But 
currently still at 17ea

Re: jpackage bugs

[Michael Hall]

> On Apr 17, 2021, at 12:14 AM, David Holmes  wrote:
> 
>> 
> 
> Note the bug referenced is closed as "incomplete" - that is a temporary state 
> while awaiting additional information  (usually from the submitter). If we 
> never hear back from the submitter then it will be closed with a different 
> (more terminal) state. If we do hear back then the bug gets reopened.

I was unaware of this distinction. Then I will attempt to come up with a 
simpler reproducible test case but I don’t know if I’ll succeed. If the test 
that didn’t reproduce that is mentioned in the comments was available I could 
try to compare that with what I am doing for differences. 

I could provide my invocation parameters to the email requesting the 
reproducer. That is my only direct involvement. If it is something else 
particular to the application itself I don’t know what that might be. Modular 
vs. my non-modular? Or something like that maybe. I think this always embeds 
the current JDK and I have checked against more than one so it doesn’t seem to 
be JDK version specific.

Thanks for pointing this status information out.

jpackage bugs

[Michael Hall]

Is there anyway to get a simple/test reference type application available that 
could be used in reproducing bugs?

I had two I think potentially serious bugs that were basically not addressed 
for problems in reproducing.

JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource is 
missing or invalid
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 


The command to reproduce was provided. The error appears to be in files 
included in the embedded JDK not being signed. So apparently not having to do 
with anything of mine. (Mentioned I now see in the comments).

As I indicate this is not a serious error for me since I am not submitting the 
app to the Mac App Store but I believe this would get the app Apple rejected 
for anyone who is attempting that. A show stopper for a major use case. It 
seems too bad to simply close it because I missed an email asking for a 
reproduce. 

With a reference application I could demonstrate the error against would 
eliminate the need to provide a separate reproducible test case. Quite sized 
for the application in question. Such an application is actually mentioned in 
the bug report comments. Could such a application be made available for 
download or user reproducing - the jpackage command and arguments?

I have looked a little bit at if to see if I can figure out how to sign the 
embedded jdk files. So far only accomplishing that I can no longer simply use 
my name for signing but have to use my fully qualified security identity. 

The question now seems to be what is in fact the difference between mine and 
the, unavailable to me, reference application as to these files verifying as 
correctly signed.

A second bug 
JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect

I thought a fix for this was all set to go in and was pulled. It was apparently 
determined that the problem only applies if the —install-dir parameter is used 
for DMG’s. Where it really makes no sense. My use apparently held over from 
when I was just creating the app.I thought this had somehow also in some way 
regressed to not reproducible. I still think a fairly simple change to the 
AppleScript as was originally planned would resolve the issue independently of 
parameters. The default DMG build I would think should _always_ indicate 
installation to the Applications folder. 

With —install-dir this remains a reproducible bug for me at 17-ea.

If a reference build was provided somewhere I might have picked up on the 
parameter difference sooner.

Re: jpackage ea-17 --mac-entitlements

[Michael Hall]

> On Apr 9, 2021, at 9:27 PM, Michael Hall  wrote:
> 
>> 
>> OK, probable user error. I eliminated my entitlement changes and it worked.
>> 
> Related to the same functionality that I am trying to add, I should, or have 
> to, make changes to my Info.plist
> This being the addition of NSAppleEventsUsageDescription. 
> If I remember correctly in prior discussion concerning application specific 
> environment variables provision was made for the user to include their own 
> custom Info.plist in the Resources directory? Is that correct? Does the file 
> name stay the same?
>  

I apparently remembered this correctly. I added the above 
NSAppleEventsUsageDescription to a copied Info.plist and it worked from the 
resources dir.

On the AppleEvent permission issue it was my misunderstanding on that. I 
thought I should pass my application bundle id for the user to give permission 
to. 
But it should be passed the ‘other’ bundle id of what I want to send events to.
So in this case with the permission request…
System.out.println(aePerm("com.apple.systemevents",true));

You can then…

exec open "/System/Library/CoreServices/System Events.app”.   [The target 
app must be running or -600 error]
us.hall.osx.AEPermit
  [This got the dialog requesting permission without hanging]
0

And an AppleScript against System Events can be run…

mps
376 Finder  com.apple.finder
/System/Library/CoreServices/Finder.app MACS
836 Mailcom.apple.mail  /System/Applications/Mail.app   emal
1338AdobeReader com.adobe.Reader/Applications/Adobe Acrobat 
Reader DC.app   CARO
2225Terminalcom.apple.Terminal  
/System/Applications/Utilities/Terminal.app 
2398HalfPipeus.hall.HalfPipe
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app
2834System Preferences  com.apple.systempreferences 
/System/Applications/System Preferences.app sprf
2855eclipse org.eclipse.platform.ide
/Users/mjh/java-2019-06/Eclipse.app 

Old AppleScript based command to get Apple specific information about running 
processes from System Events, which is an application itself I just found out.

Requesting permission for your own bundle id hangs. Otherwise no problem, and 
nothing jpackage/Java related for that matter.
But to indicate resolved.

Re: jpackage ea-17 --mac-entitlements

[Michael Hall]

> On Apr 9, 2021, at 9:27 PM, Michael Hall  wrote:
> 
> Although I believe 
> codesign -v --verbose=4 outputdir/HalfPipe.app 
> This verify would be sufficient to reproduce that error for any(?) jpackage 
> Developer signed application.

An additional thought on this might be that it would be an idea to include a 
codesign verify as part of the build. From my java command line app.

exec codesign -v /Applications/BBEdit.app
exec codesign -v /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: a sealed resource is 
missing or invalid
exec codesign -v /Applications/BBEdit.app | wc
wc: chars - 0
wc: words - 0
wc: lines - 0
exec codesign -v /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app | wc
wc: chars - 97
wc: words - 8
wc: lines - 1

Verify appears to return nothing if it succeeds and an error message if it 
doesn’t. From java it might have to check on that?

I could RFE if wanted.

Re: jpackage ea-17 --mac-entitlements

[Michael Hall]

> 
> OK, probable user error. I eliminated my entitlement changes and it worked.
> 
Related to the same functionality that I am trying to add, I should, or have 
to, make changes to my Info.plist
This being the addition of NSAppleEventsUsageDescription. 
If I remember correctly in prior discussion concerning application specific 
environment variables provision was made for the user to include their own 
custom Info.plist in the Resources directory? Is that correct? Does the file 
name stay the same?
 
If of interest what I am trying to do is pretty much as described here…
Authorization by AEDeterminePermissionToAutomateTarget waits infinit time
https://developer.apple.com/forums/thread/666528 

Except that hangs intermittently and rarely while mine always hangs.

I want to authorize automation AppleEvents for my own application. This 
consistently hangs on the above call (AEDeterminePermissionToAutomateTarget) 
done in JNI.

2442 AEDeterminePermissionToAutomateTarget  (in AE) + 1313  [0x7fff3a2d8f2c]
+   2442 
_dispatch_semaphore_wait_slow  (in libdispatch.dylib) + 98  [0x7fff72fb4fbf]
+ 2442 
_dispatch_sema4_wait  (in libdispatch.dylib) + 16  [0x7fff72fb4aed]
+   2442 
semaphore_wait_trap  (in libsystem_kernel.dylib) + 10  [0x7fff7314ee36]

I have succeeded in getting the same native code to run command line from 
Terminal. I got it to run once from my application when the application was 
launched command line, it showed a dialog, and granted permission. However, the 
dialog application showed as Terminal and not mine.. So now the functionality 
actually works if command line launched but doesn’t if double click launched. 
With the problem that it hangs if I try the permit double click launched.

So it seems Terminal must be doing something different or have different 
authorization than I do. One difference was the entitlement that I originally 
was crashing with on this list thread.

Also if of interest I determined that difference by using the Taccy 
application. 
https://eclecticlight.co/tag/taccy/ 
For Terminal this shows 

App signature check:
/System/Applications/Utilities/Terminal.app: accepted
source=Apple System
origin=Software Signing

For my application…

App signature check:
⛔️ spctl error 1
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app: a sealed resource is 
missing or invalid

I believe this relates to…
JDK-8263156 : [macos]: OS X application signing concerns - a sealed resource is 
missing or invalid
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156 


Although I believe 
codesign -v --verbose=4 outputdir/HalfPipe.app 
This verify would be sufficient to reproduce that error for any(?) jpackage 
Developer signed application.

I’m not sure what your policies are for using 3rd party tools but Taccy seems 
to give you a nice graphical view of application signing/entitlement related.

Sorry for the length,
Thanks

Re: jpackage ea-17 --mac-entitlements

[Michael Hall]

> On Apr 9, 2021, at 6:59 PM, Michael Hall  wrote:
> 
> Should bug reports be written against this yet?
> 
> I codesign generated a entitlements file and then tried adding…
> 
>com.apple.private.tcc.allow-prompting
>
> 
> I added this to my invocation…
> 
> --mac-entitlements “entitlements.xml"
> 
> And the app crashed…
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:0
> 
> Exception Type:EXC_CRASH (Code Signature Invalid)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Termination Reason:Namespace CODESIGNING, Code 0x1
> 
> This is new to me and user error is very possible. It does seem to possibly 
> be necessary for something I am trying to do.  If this is still new work in 
> progress and you would prefer bug reports to be deferred until later that’s 
> fine. If you would like the bug reports written now I can do that.

OK, probable user error. I eliminated my entitlement changes and it worked.

jpackage ea-17 --mac-entitlements

[Michael Hall]

Should bug reports be written against this yet?

I codesign generated a entitlements file and then tried adding…

com.apple.private.tcc.allow-prompting


I added this to my invocation…

--mac-entitlements “entitlements.xml"

And the app crashed…

System Integrity Protection: enabled

Crashed Thread:0

Exception Type:EXC_CRASH (Code Signature Invalid)
Exception Codes:   0x, 0x
Exception Note:EXC_CORPSE_NOTIFY

Termination Reason:Namespace CODESIGNING, Code 0x1

This is new to me and user error is very possible. It does seem to possibly be 
necessary for something I am trying to do.  If this is still new work in 
progress and you would prefer bug reports to be deferred until later that’s 
fine. If you would like the bug reports written now I can do that.

Re: RFR: JDK-8263154: [macos] DMG builds have finder errors

[Michael Hall]

Thanks

> On Mar 13, 2021, at 8:45 AM, Andy Herrick  wrote:
> 
> JDK-8263154: [macos] DMG builds have finder errors
> 
> -
> 
> Commit messages:
> - JDK-8263154: [macos] DMG builds have finder errors
> 
> Changes: https://git.openjdk.java.net/jdk/pull/2987/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2987=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8263154
>  Stats: 11 lines in 2 files changed: 7 ins; 0 del; 4 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/2987.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2987/head:pull/2987
> 
> PR: https://git.openjdk.java.net/jdk/pull/2987

Jpackage GraalVM OS X

[Michael Hall]

This appears to no longer work at all as a included JRE
With…

--runtime-image 
/Library/Java/JavaVirtualMachines/graalvm-ce-java11-21.0.0/Contents/Home \

It fails to launch. Launch CLI 

outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP
Failed to find JVM in 
"/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/runtime" 
directory.

Although it is in fact there…

ls 
/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/runtime/Contents
HomeInfo.plist  MacOS   _CodeSignature

I thought code signing might fix some other issues I had with this previously 
now that that is working.

Re: jpackage problem submitting to Apple Store

[Michael Hall]

> On Feb 1, 2021, at 9:02 AM, Andy Herrick  wrote:
> 
> This step is required to post app on web where it can be downloaded and run 
> on other machines running MacOS Catalina or later. 

This is probably all I’d be looking at for now. I’m looking at an app I wrote a 
year or two back with downloaded images and sounds. I read somewhere Apple 
rejected someone’s app because they couldn’t prove something they used was 
public domain. I am sure I couldn’t prove that for everything I used.

Re: bug jpackage in JDK 15

[Michael Hall]

> On Jan 29, 2021, at 7:37 PM, Michael Hall  wrote:
> 
> 
> 
>> On Jan 26, 2021, at 7:16 PM, Michael Hall > <mailto:mik3h...@gmail.com>> wrote:
>> 
>>> 
>>> 
>>> When I open the built dmg there is an application icon, a drag to 
>>> indicating arrow, but no application folder icon as the drag target.
>>> 
>>> Possibly related…
>>> 
>>> Running [osascript, 
>>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>>  Blastoff-dmg-setup.scpt]
>>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>>  Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: 
>>> Can’t make class alias file. (-2710)
>>> java.io.IOException: Command [osascript, 
>>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>>  Blastoff-dmg-setup.scpt] exited with 1 code
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)
> 
> This doesn’t necessarily seem to be security related. So possibly not related 
> to my other problem.
> I was going to try and re-open a bug report but that doesn’t appear currently 
> possible for me.
> 
> It seems it could possibly be the path for the Applications folder. Say if 
> you want something nice to get a name without a forward slash.
> Based on DMGSetup.scpt…
> 
> tell application "Finder"
>   set DEPLOY_VOLUME_PATH to "/Volumes/TestImage/"
>   set DEPLOY_INSTALL_LOCATION to "Applications"
>   set DEPLOY_INSTALL_NAME to "Applications"
>   make new alias file at POSIX file DEPLOY_VOLUME_PATH to POSIX file 
> DEPLOY_INSTALL_LOCATION with properties {name:DEPLOY_INSTALL_LOCATION}
> end tell
> 
> tell application "Finder"
>   make new alias file at file "TestImage:" to file ":Applications" with 
> properties {name:"Applications"}
> Result:
> error "Finder got an error: Can’t make class alias file." number -2710 from 
> alias file to class
> 
> You get the same error. Note INSTALL_LOCATION is used for both destination 
> and name.
> 
> If you make that a correct path with forward slash but have a separate name 
> variable without forward slash for the name.
> 
> tell application "Finder"
>   make new alias file at file "TestImage:" to file "Macintosh 
> HD:Applications:" with properties {name:"Applications"}
> end tell
> Result:
> alias file "Applications" of disk "TestImage" of application “Finder”
> 
> It works. I’m not sure unless something changed why that would suddenly be 
> broke but it does seem to be for DMG’s. 

This was a hypothetical, hopefully plausible, possibility that reproduced the 
actual error. I don’t work on the JDK and don’t know how I would debug to get 
the values actually being passed. Possibly a ‘debug’ option where the script 
output is saved instead of being written to a temporary file and disappearing 
could be useful?

Re: bug jpackage in JDK 15

[Michael Hall]

> On Jan 26, 2021, at 7:16 PM, Michael Hall  wrote:
> 
>> 
>> 
>> When I open the built dmg there is an application icon, a drag to indicating 
>> arrow, but no application folder icon as the drag target.
>> 
>> Possibly related…
>> 
>> Running [osascript, 
>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>  Blastoff-dmg-setup.scpt]
>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>  Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: 
>> Can’t make class alias file. (-2710)
>> java.io.IOException: Command [osascript, 
>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>  Blastoff-dmg-setup.scpt] exited with 1 code
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
>>  at 
>> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)

This doesn’t necessarily seem to be security related. So possibly not related 
to my other problem.
I was going to try and re-open a bug report but that doesn’t appear currently 
possible for me.

It seems it could possibly be the path for the Applications folder. Say if you 
want something nice to get a name without a forward slash.
Based on DMGSetup.scpt…

tell application "Finder"
set DEPLOY_VOLUME_PATH to "/Volumes/TestImage/"
set DEPLOY_INSTALL_LOCATION to "Applications"
set DEPLOY_INSTALL_NAME to "Applications"
make new alias file at POSIX file DEPLOY_VOLUME_PATH to POSIX file 
DEPLOY_INSTALL_LOCATION with properties {name:DEPLOY_INSTALL_LOCATION}
end tell

tell application "Finder"
make new alias file at file "TestImage:" to file ":Applications" with 
properties {name:"Applications"}
Result:
error "Finder got an error: Can’t make class alias file." number -2710 from 
alias file to class

You get the same error. Note INSTALL_LOCATION is used for both destination and 
name.

If you make that a correct path with forward slash but have a separate name 
variable without forward slash for the name.

tell application "Finder"
make new alias file at file "TestImage:" to file "Macintosh 
HD:Applications:" with properties {name:"Applications"}
end tell
Result:
alias file "Applications" of disk "TestImage" of application “Finder”

It works. I’m not sure unless something changed why that would suddenly be 
broke but it does seem to be for DMG’s. 

Re: bug jpackage in JDK 15

[Michael Hall]

> 
> When I open the built dmg there is an application icon, a drag to indicating 
> arrow, but no application folder icon as the drag target.
> 
> Possibly related…
> 
> Running [osascript, 
> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>  Blastoff-dmg-setup.scpt]
> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>  Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: 
> Can’t make class alias file. (-2710)
> java.io.IOException: Command [osascript, 
> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>  Blastoff-dmg-setup.scpt] exited with 1 code
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
>   at 
> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)
> 
> Also it seems...
> --add-modules java.desktop,java.prefs,java.se \
> 
> Is no longer an option?
> —help doesn’t show it and I end up with…
> java-options=--module-path
> 
> In the .cfg

Fwiw I was curious if this was a known issue.
https://bugs.openjdk.java.net/browse/JDK-8250615 


It seems like this might still be an open issue?
I am guessing new Folder security on OS X Catalina. If so I would be interested 
in hearing of any resolution. I have had another problem with a java app on the 
Documents folder.

Re: jpackage problem submitting to Apple Store

[Michael Hall]

> On Jan 25, 2021, at 6:36 AM, John Crowley  wrote:
> 
> As an alternate, a link to Google Drive - 
> https://drive.google.com/drive/folders/1SgLhlovuH2x18gRh-ffhZCHVeXt1AOXo?usp=sharing
>  
> 
> 

The attachments are there

Re: jpackage problem submitting to Apple Store

[Michael Hall]

> On Jan 24, 2021, at 8:28 AM, John Crowley  wrote:
> 
> Hi All,
> 
> Have been having a problem trying to use jpackage to sign an app and submit 
> it to the Apple Store.
> 
> Attached are the following:

No attachments that I’m seeing.

Re: bug jpackage in JDK 15

[Michael Hall]

> On Jan 24, 2021, at 7:37 AM, Michael Hall  wrote:
> 
> 
> --name 'VARS Annotation’ 
> 
> You are using a name with an embedded blank but that didn’t seem to cause me 
> any problems.
> 
> I didn’t recreate, maybe if I get a chance I’ll try to see if anything else 
> in your invocation seems to trigger what you’re seeing.

This is about as close to yours as I think I can get and I didn’t recreate, it 
is how I run mine shell script…

#!/bin/bash

set -e

PACKAGER=`/usr/libexec/java_home`/bin/jpackage

${PACKAGER} --version

echo 'remove prior dist'
rm -rf outputdir
mkdir outputdir

#   --install-dir outputdir \
#   --add-modules java.desktop,java.prefs,java.se \

${PACKAGER} \
--verbose \
--type app-image \
--input ./input \
--dest outputdir \
--app-version 1.0.0  \
--name BlackJack\ Blastoff \
--main-jar bjb.jar \
--main-class org.bjb.BlackJackApp \
--runtime-image 
/Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home \
--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50  
-Dapple.laf.useScreenMenuBar=true 
-Dcom.apple.mrj.application.apple.menu.about.name=BlackjackBlastoff 
-Dapple.awt.application.name=Blackjack\ Blastoff' \
--icon /Users/mjh/HalfPipe/HalfPipe_jpkg/GenericApp.icns
 
#   --mac-sign \
#   --mac-signing-key-user-name "Michael Hall”

I think is about everything you had except different —java-options, mine of 
course excluding your modular related.

ls "outputdir/BlackJack Blastoff.app”

Contents

ls "outputdir/BlackJack Blastoff.app/Contents"
Info.plist  MacOS   PkgInfo Resources   app 
runtime

If you use /usr/libexec/java_home you can get the current jdk and not need to 
hardcode the path into JavaVirtualMachines. It looks like you only maintain one 
version of the JDK, the release appeared stripped in your path? This also 
allows you to run other versions if you want like…

/usr/libexec/java_home -v 14 --exec jpackage --version
WARNING: Using incubator modules: jdk.incubator.jpackage
14.0.2

If of interest to anyone I still haven’t figured out signing. It errored giving 
some indication that the JDK had already been signed? I posted that sometime 
back. I keep meaning to look at what there is for testing but haven’t yet. Any 
thoughts on that would still be appreciated.

Re: bug jpackage in JDK 15

[Michael Hall]

--name 'VARS Annotation’ 

You are using a name with an embedded blank but that didn’t seem to cause me 
any problems.

I didn’t recreate, maybe if I get a chance I’ll try to see if anything else in 
your invocation seems to trigger what you’re seeing.

Re: bug jpackage in JDK 15

[Michael Hall]

> On Jan 23, 2021, at 7:07 PM, Michael Hall  wrote:
> 
> Also it seems...
> --add-modules java.desktop,java.prefs,java.se <http://java.se/> \
> 
> Is no longer an option?
> —help doesn’t show it and I end up with…
> java-options=--module-path
> 
> In the .cfg

Sorry, checked again and that is still in —help, probably not passed on to the 
cfg though?
The empty —module-path java option is probably unrelated. 

Re: bug jpackage in JDK 15

[Michael Hall]

> On Jan 23, 2021, at 7:07 PM, Michael Hall  wrote:
> 
> 
> 
>> On Jan 23, 2021, at 6:02 AM, Michael Hall  wrote:
>> 
>> 
>>> 
>>> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
>>> JDK15
>>> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
>>> 
>> 
>> Any chance the embedded blank in the app name is throwing something off?
>> 
> 
> 
> 
> I installed jdk 15 and am not seeing this problem. Including with a embedded 
> blank app name.
>   --name BlackJack\ Blastoff \
> 

Versions if apply

...jpackage --version
WARNING: Using incubator modules: jdk.incubator.jpackage
15.0.2

macOS Catalina 10.15.7

Re: bug jpackage in JDK 15

[Michael Hall]

> On Jan 23, 2021, at 6:02 AM, Michael Hall  wrote:
> 
> 
>> 
>> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
>> JDK15
>> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
>> 
> 
> Any chance the embedded blank in the app name is throwing something off?
> 



I installed jdk 15 and am not seeing this problem. Including with a embedded 
blank app name.
--name BlackJack\ Blastoff \

When I open the built dmg there is an application icon, a drag to indicating 
arrow, but no application folder icon as the drag target.

Possibly related…

Running [osascript, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
 Blastoff-dmg-setup.scpt]
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
 Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: Can’t 
make class alias file. (-2710)
java.io.IOException: Command [osascript, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
 Blastoff-dmg-setup.scpt] exited with 1 code
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)

Also it seems...
--add-modules java.desktop,java.prefs,java.se \

Is no longer an option?
—help doesn’t show it and I end up with…
java-options=--module-path

In the .cfg

Re: bug jpackage in JDK 15

[Michael Hall]

> 
> "[...]/VARS Annotation.app/Contents/Contents/app/VARS Annotation.cfg" #
> JDK15
> "[...]/VARS Annotation.app/Contents/app/VARS Annotation.cfg" # JDK14
> 

Any chance the embedded blank in the app name is throwing something off?

Re: jpackage OS X codesign IOException

[Michael Hall]

> On Sep 26, 2020, at 6:57 AM, Michael Hall  wrote:
> 
> java.io.IOException: Command [codesign, -s, Developer ID Application: X 
> (X), -, 
> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage16414030388823297270/images/image-1807061985031173/HalfPipe.app]
>  exited with 1 code
> 
> X values changed by me

With —verbose

Running [codesign, -s, Developer ID Application: Michael Hall (XXX), -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app]
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app:
 is already signed
java.io.IOException: Command [codesign, -s, Developer ID Application: Michael 
Hall (), -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app]
 exited with 1 code
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:73)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:179)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:150)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacAppImageBuilder.signAppBundle(MacAppImageBuilder.java:895)
…

jdk.incubator.jpackage.internal.PackagerException: java.io.IOException: Command 
[codesign, -s, Developer ID Application: Michael Hall (XXX), -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app]
 exited with 1 code
…

Caused by: java.io.IOException: Command [codesign, -s, Developer ID 
Application: Michael Hall (XXX), -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app]
 exited with 1 code
…

Skipping part of stack trace. Changing the id assigned me to XX again. 
Leaving my name, not exactly top secret I guess. I was wondering if there was a 
problem with the embedded blank in the name but that doesn’t seem to go with…
/HalfPipe.app: is already signed

Many individual files appear to be successfully signed prior to that. 
There is this, suggesting maybe some runtime signing has already been done?

Running [codesign, -f, -s, Developer ID Application: Michael Hall (XXX), 
--prefix, us.hall.hp.common., -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app/Contents/runtime]
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app/Contents/runtime:
 replacing existing signature
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app/Contents/runtime:
 signed bundle with Mach-O thin (x86_64) [com.oracle.java.us.hall.HalfPipe]
Running [codesign, -s, Developer ID Application: Michael Hall (XXX), 
--prefix, us.hall.hp.common., -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app/Contents/runtime/Contents/_CodeSignature/CodeResources]
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage2558190777911372665/images/image-996994285608642/HalfPipe.app/Contents/runtime/Contents/_CodeSignature/CodeResources:
 signed generic [us.hall.hp.common.CodeResources]

Re: jpackage OS X codesign IOException

[Michael Hall]

> On Sep 26, 2020, at 7:13 AM, Michael Hall  wrote:
> 
> 
> 
>> On Sep 26, 2020, at 7:09 AM, Bernd Eckenfels  wrote:
>> 
>> Looks like the codesign command is not in your PATH
>> 
> 
> which codesign
> /usr/bin/codesign
> 

PATH= … /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin ...

Re: jpackage OS X codesign IOException

[Michael Hall]

> On Sep 26, 2020, at 7:09 AM, Bernd Eckenfels  wrote:
> 
> Looks like the codesign command is not in your PATH
> 

which codesign
/usr/bin/codesign

jpackage OS X codesign IOException

[Michael Hall]

java.io.IOException: Command [codesign, -s, Developer ID Application: X 
(X), -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage16414030388823297270/images/image-1807061985031173/HalfPipe.app]
 exited with 1 code

X values changed by me

Re: Jpackage file assocations OS X

[Michael Hall]

> On Sep 22, 2020, at 7:35 PM, alexander.matv...@oracle.com wrote:
> 
> Hi Michael,
> 
> For file association you will need to create property file and pass it to 
> jpackage via --file-associations.

Thanks for the detailed reply. I will look closer at it later. I had found the 
test class. I was looking in the incubator directory and not tool previously. 
Between your reply and that should be able to understand how it should work OS 
X.

Re: Jpackage file assocations OS X

[Michael Hall]

> On Sep 22, 2020, at 1:47 PM, Andy Herrick  wrote:
> 
> Alexander:
> 
> Can you explain the mechanism by which a macosx application is expected to 
> retrieve the path to the selected file when the app is invoked via a file 
> association ?
> 
> On mac, the path to the associated file is not passed as an argument (as it 
> is on Linux and Windows).
> 
> /Andy
> 
> On 9/20/2020 8:40 PM, Michael Hall wrote:
>> Are there any examples or further information on how the file association 
>> property file should work?
>> It is not entirely clear to me from the command help.
>> 
>> 

Is this currently not intended to be supported on OS X at this time? As I 
remember you have the extensions and what role they have for the application 
and things like that. These being entries in the Info.plist. It wasn’t clear to 
me how that would be applied in a properties file.

Jpackage file assocations OS X

[Michael Hall]

Are there any examples or further information on how the file association 
property file should work?
It is not entirely clear to me from the command help.

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

>> 
>> This is not how I’ve done it before. I did a little googling and it seemed 
>> to indicate launchctl could somehow be used for ‘global’ environment 
>> variables. It didn’t sound application specific.
> 
> Right it isn’t application specific.  If you need a separate environment for 
> your application, that wouldn’t work.  But if you are passing parameters that 
> are specific to the application launcher, why use environment variables at 
> all?

See my prior examples of usage. Basically because other code requires the 
environment variables to be there.

> 
> 
>> The incident mentioned earlier showed a resolution of having the user 
>> provide their own custom Info.plist. 
> 
> Just use a config file that can be platform independent.  Modifying the 
> Info.plist for each specific install smells wrong.

Because modifying the Info.plist is only way to do it. 

To the incident https://bugs.openjdk.java.net/browse/JDK-8233175 

Doing some testing with plistbuddy it does seem to work following the 
resolution. It appears to even work without following the resolution. Possibly 
though that might break signed applications.

Following the resolution I took the Info.plist from a application and put it 
into a template/ directory.
Then doing…
cp template/Info.plist resources/Info.plist
/usr/libexec/plistbuddy -c 'Add:NSRequiresAquaSystemAppearance bool false' 
resources/Info.plist
And including this on the jpackage invocation…
--resource-dir resources \
We get…
/usr/libexec/plistbuddy -c print outputdir/HalfPipe.app/Contents/Info.plist
Dict {
CFBundleName = HalfPipe
CFBundleIdentifier = us.hall.HalfPipe
CFBundleInfoDictionaryVersion = 6.0
LSApplicationCategoryType = Unknown
CFBundleVersion = 1.0
CFBundleExecutable = HalfPipe
CFBundleAllowMixedLocalizations = true
NSHighResolutionCapable = true
CFBundlePackageType = APPL
CFBundleIconFile = HalfPipe.icns
CFBundleSignature = 
NSRequiresAquaSystemAppearance = false
LSMinimumSystemVersion = 10.9
CFBundleDevelopmentRegion = English
NSHumanReadableCopyright = Copyright (C) 2020
CFBundleShortVersionString = 1.0
}

Including the incident mentioned NSRequiresAquaSystemAppearance. Setting it off 
appears to be about the only reason you would want to include the plist entry.

As I said this will also work by just directly working with the application 
Info.plist, at least as long as the application is unsigned. I don’t know if it 
would invalidate a signed signature. Probably best if it did, then the 
—resource-dir would be needed. 

For environment variables I checked my manual changes with the application 
where I can ‘exec env’ and they seemed set correctly. So I’m not sure yet what 
actual difference between shell invoked and Finder invoked is the issue. 
Possibly not that I have the environment variables wrong. 

So. If anyone actually wants to update the plist as part of the build 
plistbuddy seems a valid way to go. Doing this one time up front and assuming 
the plist never changes would be another. Xcode provides an editor if you only 
have to do a one time change and want to do that manually. 
plistbuddy almost seems a way jpackage could provide the functionality itself 
at some point fairly easily? It was included on my machine although I’m not 
sure how officially Apple supports it. Xcode native app developers do seem to 
use it in their builds so you would think it would not casually disappear.
You might consider it sometime. 

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> 
> The incident mentioned earlier showed a resolution of having the user provide 
> their own custom Info.plist. While plain old edit would probably be fine for 
> this some sort of code to provide it without manual intervention might also 
> be nice. I believe I have some old code lying around that might just provide 
> a beginning for such a thing.

As another possible alternative for working with an Info.plist this was 
recently mentioned on I think it was a Cocoa mail list. 
https://medium.com/@marksiu/what-is-plistbuddy-76cb4f0c262d 

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Sep 3, 2020, at 7:12 AM, Scott Palmer  wrote:
> 
> 
> 
>> On Sep 3, 2020, at 4:26 AM, Michael Hall > <mailto:mik3h...@gmail.com>> wrote:
>> 
>> 
>> 
>>> On Sep 2, 2020, at 10:07 PM, Scott Palmer >> <mailto:swpal...@gmail.com>> wrote:
>>> 
>>> There is already a way to supply a custom Info.plist.  
>>> That can have the LSEnvironment entries you want.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8233175 
>>> <https://bugs.openjdk.java.net/browse/JDK-8233175>
>>> 
>>> I was under the impression that we were after something that would allow 
>>> different values to get to the application based on environment variables.  
>>> The env var values can’t be hard-coded in the Info.plist to do that, we 
>>> want values that are expanded based on set environment variables on the 
>>> user’s machine.  Isn’t that what this is about?
>>> 
>>> Scott
>> 
>> Yes for Serban’s thread. Which was already shown not to work OS X on the 
>> users machine because user environment variables aren’t passed to 
>> applications. 
> 
> As I mentioned earlier, launchctl must be used to set environment variables 
> that you want passed to GUI applications.

This is not how I’ve done it before. I did a little googling and it seemed to 
indicate launchctl could somehow be used for ‘global’ environment variables. It 
didn’t sound application specific. I have successfully done this on a 
application basis a couple times in the past as I mentioned earlier. Also from 
the old javafx JavaPackager I also mentioned earlier is this in Info.plist.vtl…

#if ($info.bundleJre)
LSEnvironment

JAVA_HOME

Contents/PlugIns/${info.jreDirectoryName}/Contents/Home
#if($info.envPath)
PATH
${info.envPath}
#end


The incident mentioned earlier showed a resolution of having the user provide 
their own custom Info.plist. While plain old edit would probably be fine for 
this some sort of code to provide it without manual intervention might also be 
nice. I believe I have some old code lying around that might just provide a 
beginning for such a thing.

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Sep 2, 2020, at 10:07 PM, Scott Palmer  wrote:
> 
> There is already a way to supply a custom Info.plist.  
> That can have the LSEnvironment entries you want.
> 
> https://bugs.openjdk.java.net/browse/JDK-8233175 
> 
> 
> I was under the impression that we were after something that would allow 
> different values to get to the application based on environment variables.  
> The env var values can’t be hard-coded in the Info.plist to do that, we want 
> values that are expanded based on set environment variables on the user’s 
> machine.  Isn’t that what this is about?
> 
> Scott

Yes for Serban’s thread. Which was already shown not to work OS X on the users 
machine because user environment variables aren’t passed to applications. Since 
the interest there mainly seemed to be turning environment variables into jdk 
option parameters for that part your stub launcher was a more valid suggestion. 
The original is not the purpose of environment variables that interested me. I 
think might of been a little questionable trying to use for this purpose. I had 
sort of been still been discussing my own separate question on providing the 
application environment variables Doing it on this thread probably wasn’t 
proper.  Sorry.

> https://bugs.openjdk.java.net/browse/JDK-8233175 
> 
OK. Basically this gives a plugin method to provide your own Info.plist. As of 
yet undocumented. That documentation still being as far as I know jpackage 
—help. Info.plist is not normally placed into the resources directory. I assume 
the issue resolution involves simply moving the Info.plist out of that 
directory to where it actually should be. 

--resource-dir 
  Path to override jpackage resources
  Icons, template files, and other resources of jpackage can be
  over-ridden by adding replacement resources to this directory.
  (absolute path or relative to the current directory)

Everything mentioned in the —help properly I think ends up in a OS X 
applications resources directory. Although I just get the icns. 

ls outputdir/HalfPipe.app/Contents/Resources
HalfPipe.icns

But it is not usually the spot for Info.plist. As a work-around it probably 
does work.

It does make the Info.plist (plugin?) provider responsible for everything that 
goes into the plist that jpackage would normally handle. Like 
--mac-package-identifier. But that is fine I guess. Being able to sort of 
custom plugin parts of the build might be nice. Rather than try to have 
jpackage handle everything from start to finish in one pass for everything that 
every application needs based solely on parameters. In this case I think maybe 
though having a explicit parameter indicating this is the developers wish might 
be cleaner? Something like —mac-info-plist .

Maybe I’ll go back to the recent situation where a PATH environment variable 
seemed to be needed and see if I can in fact come up with plugin type code that 
puts together a Info.plist that works. 

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Sep 2, 2020, at 12:14 PM, Scott Palmer  wrote:
> 
> If your app need to use environment variables to configure something for 
> runtime it is probably best to have your own stub launcher and launch a 
> sub-process.  

They need to be available at runtime for external native that expects them to 
be present. 

> 
> It can be tricky to have a smooth user experience with that though. You would 
> want to avoid an extra icon in the dock/start bar. You don’t want the other 
> process to show up as “java.exe”, etc.  That’s the benefit of trying to solve 
> this in the launcher created by jpackage. 
> 

What I am suggesting would be handled by jpackage within the application 
bundle. It would modify the Info.plist to include the LSEnvironment entries.

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Sep 2, 2020, at 9:04 AM, Andy Herrick  wrote:
> 
> Yes - environment variables are not a good answer for this, not just mac, but 
> even on windows the env variables at run time are different if launched from 
> a shell (the env variables of that shell) vs. when run from a shortcut (the 
> system-wide or user env variables set in Control Panel or Settings dialog).
> 
> JEP-343 says jpackage should be "a tool for packaging self-contained Java 
> applications.", so an app packaged with jpackage should run on a machine 
> without requiring any other files to be installed .  That should not prohibit 
> optional configuration from being discovered on a machine and used to tune 
> the application or it's use of Java.
> 
> Normally, any such discovery can be done by the application itself, except 
> where it is the the java options that tune the java vm itself, and that is 
> why we are considering mechanisms (such as expanding environment variables at 
> runtime, or reading an installed configuration file of some kind)
> 
It’s difficult and was difficult with java applications on OS X from the start 
to have an application support anything like command line invoking with 
parameters.

Maybe add standalone options for the command that update an existing 
application bundle? Of course then there would probably be signing and other 
issues.

Again, for LSEnvironment on OS X I think it wouldn’t be terribly difficult to 
implement. You could handle it something like it appears file associations 
work. Although, I haven’t done anything with those yet. Then just modify the 
Info.plist. I have had code that does that in the past. XML right?

In the past I have had need to add environment variables to my application to 
interface it with the R language. Also  debugging AppleScript related at one 
point required environment variables. It was very much an OS X only java app at 
one point in time.
Recently I had problems interfacing to Anaconda python that it seemed like 
being able to set the PATH variable might resolve. Although my own attempts to 
set the variables to get it to work failed. What did work was command line 
shell invoking the application. Like myApp.app/Contents/MacOS/myApp from 
Terminal. That was for someone else’s application.
I decided just to set a alias for that in .bash_profile for my own use and not 
try to figure what exactly the Finder launched application needed to make it 
work.
So these are some use cases where environment variables were involved. A 
feature to support them could occasionally be nice. 

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> 
> On macOS you need to set the variables differently, but I think it can still 
> work. The variables known to your shell are not the same as those known to 
> LaunchServices. For those use the launchctl command to set them. 
> 

I’m not that familiar with launchctl. Is this something the application user is 
expected to do? What experience I have had with applications and environment 
variables involved adding the entries to Info.plist. Making the environment 
variables normally available to the application as environment variables. 

My question is if there is or will be any kind of OS X support for this in 
jpackage? LSEnvironment settings in the Info.plist file. 

e.g. the following was what was recently mentioned on the javafx list…
https://github.com/fvarrui/JavaPackager 

envPath

Defines PATH environment variable in GNU/Linux and Mac OS X startup scripts.


Otherwise, this seems to be getting a little confusing, for me anyhow, as to 
what you’re trying to do and when. Are you trying to use environment variables 
at build time to replace variables that will be resolved in the config file. 
Which seemed to be what Serban was asking. Or did I misunderstand that and 
Serban actually wants settings that will be resolved at application launch? 
Or do you want to use them at application launch time as some kind of mechanism 
to override config file settings there like jdk memory settings? Which seems to 
what the jdk issue concerned. 

My question seems simpler. I will let others resolve other environment variable 
usage at build or launch time. I am interested in runtime. 

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> 
>> Is there a way to pass values from environment variables when using
>> --java-options?
>> 
>> It would be nice to be able to write something like this:
>> --java-options "-DmyAppData=$HOME/.myData"
>> 
>> (Instead of using the $ sign, another notation may be more appropriate, in
>> order to not conflict with macros such as $APPDIR or $ROOTDIR.)
> Although I don't think there is a problem conflicting with the existing 
> macros for $ROOTDIR, $APPDIR, or $BINDIR, we may need something more 
> exclusive that "$" since dollar sign may be a legitimate character in an 
> existing argument or vm option ("-DPRICE=$10.50") or ("-DCURRENCY_TAG=$")
> 
> anyway, wouldn't this go a long way to alleviating the concerns of 
> JDK-8250950  ?
> 
> 
If I follow the referenced issue, after a quick browse, it wants to satisfy the 
need for different user memory specifications. It proposes doing this with a 
standalone configuration file that could override the one jpackage uses. So 
could be used for more general overrides.
You are now thinking environment variables could provide the override without 
the need for a second user/developer configuration file? 
I am not sure that works. Actually, I don’t think the environment variable 
settings would be very useful on OS X at all after considering this issue. 
On OS X applications get a default set of environment variables not dependent 
on user ones. 
Looking like this from an application of mine…

exec env
TMPDIR=/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0y for 
HOME=/Users/mjh
SHELL=/bin/bash
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.sZlyFCZcWZ/Render
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.f11OdXASJN/Listeners
PATH=/usr/bin:/bin:/usr/sbin:/sbin
LOGNAME=mjh
DISPLAY=/private/tmp/com.apple.launchd.rN2uW3mk7s/org.macosforge.xquartz:0
XPC_SERVICE_NAME=us.hall.FastRGraalHP.35068
USER=mjh
XPC_FLAGS=0x0

My own settings from Terminal (.bash_profile) are more involved say for the 
PATH variable…

env | grep PATH
PATH=/Users/mjh/anaconda3/bin:/Users/mjh/anaconda3/condabin:/opt/ooRexx/bin:/usr/local/Cellar/watchman/4.9.0_3/bin:/Users/mjh/management/spark-2.4.3-bin-hadoop2.7/bin:/Users/mjh/management/apache-maven-3.6.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
...

So I’m not sure passing things to the application at launch time by environment 
variable would work? At least OS X. If as I think the issue indicated you 
wanted a cross-platform solution.

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Sep 1, 2020, at 10:30 AM, Andy Herrick  wrote:
> 
> I have been following this discussion , and feel it is worth pursuing.
> 
> Currently , the values of --arguments and --java-options are pre-processed at 
> launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to 
> values determined by the native launchers.
> 
> If we can do so without breaking existing functionality we should also expand 
>  environment variables to their values at launch time.
> 
> example:  "--java-options \$USER_JAVA_OPTIONS", "--java-options 
> -Dfoo=\$USER_BAR_VALUE",  "--arguments \$USER_MYAPP_ARGS"
> 
> Developer would have to make sure that the resulting java options or app 
> arguments make sense both with and without the corresponding environment 
> variable set.  jpackage could make sure that an empty option or argument did 
> not cause a problem (as in first and third example above when there is no 
> corresponding env setting).

Actually I think about Serban’s original idea. Which seems would be workable in 
a lot of cases. Unless you actually need it to be an environment variable.

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Sep 1, 2020, at 9:23 AM, Michael Hall  wrote:
> 
> 
> 
>> On Sep 1, 2020, at 2:07 AM, Serban Iordache  
>> wrote:
>> 
>> Not sure if it was clear from my previous messages, but what I am asking for 
>> is that the environment variables are expanded with the values they have on 
>> the user's machine (not on the machine where jpackage has been executed).  
> 
> It might be better at this point for the developers to respond. 
> 
> However, I believe on probably all platforms these options are included in a 
> .cfg file that is bundled with the application. It is set at build time and 
> not in anyway dynamic at runtime. Unless maybe you had some pre-launch 
> process that modified that .cfg file?
> 
> On OS X I believe true application environment variables can be set in the 
> Info.plist file, LSEnvironment entries if I remember correctly. A fork of the 
> javapackager tool previously used in association with JavaFX was 
> recently.mentioned on that list (JavaFX). I saw it included support for the 
> PATH environment variable. On OS X using LSEnvironment as mentioned. I didn’t 
> see this on the jpackage —help and wondered if any such support was currently 
> included in jpackage. 
> 
> It is a valid point I was overlooking that some of this might be user 
> dependent and changes to PATH or other environment variables might not be 
> valid for all users unless care was taken. Again, difficult to take care with 
> everything set at build time. 

Of course there is the code that reads the .cfg file. Thinking about it that 
could possibly be modified to resolve some dynamic variable type settings as it 
reads it. 

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Sep 1, 2020, at 2:07 AM, Serban Iordache  wrote:
> 
> Not sure if it was clear from my previous messages, but what I am asking for 
> is that the environment variables are expanded with the values they have on 
> the user's machine (not on the machine where jpackage has been executed).  

It might be better at this point for the developers to respond. 

However, I believe on probably all platforms these options are included in a 
.cfg file that is bundled with the application. It is set at build time and not 
in anyway dynamic at runtime. Unless maybe you had some pre-launch process that 
modified that .cfg file?

On OS X I believe true application environment variables can be set in the 
Info.plist file, LSEnvironment entries if I remember correctly. A fork of the 
javapackager tool previously used in association with JavaFX was 
recently.mentioned on that list (JavaFX). I saw it included support for the 
PATH environment variable. On OS X using LSEnvironment as mentioned. I didn’t 
see this on the jpackage —help and wondered if any such support was currently 
included in jpackage. 

It is a valid point I was overlooking that some of this might be user dependent 
and changes to PATH or other environment variables might not be valid for all 
users unless care was taken. Again, difficult to take care with everything set 
at build time. 



 

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Aug 31, 2020, at 3:07 PM, Michael Hall  wrote:
> 
> 
> 
>> On Aug 29, 2020, at 3:37 AM, Serban Iordache  
>> wrote:
>> 
>> Hi,
>> 
>> Is there a way to pass values from environment variables when using
>> --java-options?
>> 
>> It would be nice to be able to write something like this:
>> --java-options "-DmyAppData=$HOME/.myData”
> 
> For this couldn’t you just pass the parameter without the path and then add 
> it later?
> 
> -DmyAppData=/.myData
> 
> final String HOME = System.getProperty(“user.home”);
> System.setProperty(“myAppData”,HOME+System.getProperty(myAppData),”.myData”);

For user data these days don’t many platforms have preferred places for user 
data other than user home?
It has occurred to me it might be nice of java had an API that actually 
automatically gave you the correct directory for a given platform to put your 
data. Maybe different locations for different types of user data.

jpackage environment variables - OS X

[Michael Hall]

Is there a way on OS X to set these in the Info.plist?

Re: jpackage: support for environment variables in --java-options

[Michael Hall]

> On Aug 29, 2020, at 3:37 AM, Serban Iordache  
> wrote:
> 
> Hi,
> 
> Is there a way to pass values from environment variables when using
> --java-options?
> 
> It would be nice to be able to write something like this:
> --java-options "-DmyAppData=$HOME/.myData”

For this couldn’t you just pass the parameter without the path and then add it 
later?

-DmyAppData=/.myData

final String HOME = System.getProperty(“user.home”);
System.setProperty(“myAppData”,HOME+System.getProperty(myAppData),”.myData”);

OS X jpackage exception FYI

[Michael Hall]

Doesn’t appear to be causing any problems to the application build?

WARNING: Using incubator modules: jdk.incubator.jpackage
14.0.2

Running [/usr/bin/SetFile, -c, icnC, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15486534363011883928/images/FastRGraalHP/.VolumeIcon.icns]
Running [/usr/bin/SetFile, -a, C, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15486534363011883928/images/FastRGraalHP]
Running [osascript, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15486534363011883928/config/FastRGraalHP-dmg-setup.scpt]
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15486534363011883928/config/FastRGraalHP-dmg-setup.scpt:57:61:
 execution error: Finder got an error: Can’t get disk "FastRGraalHP". (-1728)
java.io.IOException: Command [osascript, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15486534363011883928/config/FastRGraalHP-dmg-setup.scpt]
 exited with 1 code
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:73)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:179)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:150)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:348)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:75)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:451)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:641)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97)
at 
jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51)

Command issued:

${PACKAGER} \
--verbose \
--input ../HalfPipe12.app/Contents/Java \
--icon GenericApp.icns \
--install-dir outputdir \
--name FastRGraalHP \
--main-jar halfpipe.jar \
--main-class us.hall.hp.common.LoaderLaunchStub \
--runtime-image 
/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home \
--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50 
-Djava.security.policy=$APPDIR/all.policy -Dapple.laf.useScreenMenuBar=true 
-Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe -Dconsole=pane' \
--mac-package-identifier us.hall.FastRGraalHP

Re: jpackage and alternate JRE's - OS X

[Michael Hall]

> On Mar 17, 2020, at 3:28 PM, Andy Herrick  wrote:
> 
> But the executables in the jdk itself are signed, including those packaged as 
> a resource like jpackageapplauncher itself.

Not that there isn’t good reason to do this but it appears to be the issue for 
GraalVM.
I set up a shell script to launch the app and that works. 
I had to change it to all access.

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

Or it had permission problems it looked like trying to read it’s etc/Renviron 
file.

I guess I’ll try to figure out where to flag this as a possible upcoming 
concern  on the GraalVM project if jpackage becomes the preferred way to 
prepare applications. Otherwise it seems like jpackage would work fine with 
their alternate jdk 11.

Re: jpackage and alternate JRE's - OS X

[Michael Hall]

> On Mar 17, 2020, at 3:28 PM, Andy Herrick  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.

Re: jpackage and alternate JRE's - OS X

[Michael Hall]

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

jpackage and alternate JRE's - OS X

[Michael Hall]

I was looking at GraalVM in order to try out FastR, a jre based R language 
implementation.

It seemed to me if it was actually a standalone JRE I should be able to use 
jpackage to turn it into an application. Or use my usual application for trying 
things out but just replace the runtime.

It seems to work for running the application. I seem to be able to use the 
included RScript command to run R files. I can’t use the R command due to 
limitations in my own code. Otherwise the normal application functionality 
appears to work.

However, If I try a simple test for programmatic R access the application 
crashes with…

Exception Type:EXC_BAD_ACCESS (Code Signature Invalid)

If I check…

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.

I guess my question would be if it could be possible to omit the signing. Where 
I assume the application would be subject to the usual  Gatekeeper ‘use at your 
own risk’ messages. But could be runnable.

I see there are signing parameters in the help but I currently don’t have ADC 
certificates. That includes —mac-sign to indicate signing should be done. Could 
 there be some way to get none?

Or supported is that you must get the signing certs? 

It doesn’t make sense to me that you can fully use the included commands but 
can’t have programmatic access. How is that less secure? But it seems to be the 
case. 

I realize jpackage is probably not intended to support GraalVM.  But it is 
possible it’s use could be extended even if unsupported.

Re: jpackage current status

[Michael Hall]

> On Feb 24, 2020, at 4:07 PM, Andy Herrick  wrote:
> 
> 
> 
> 
> then in app you can find any of the tools by using 
> System.getProperty("java.home") and looking in "bin" subdir.
> 
> So in the app you can refer to any of the tools by their full path.
> 

Not to keep dragging this on. But I did notice JShell seems to need the java 
command. Without it…

Caused by: java.lang.InternalError: Failed remote listen: java.io.IOException: 
Cannot run program 
"/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java":
 error=2, No such file or directory @ com.sun.jdi.SocketListen (defaults: 
timeout=, port=, localAddress=) -- {timeout=timeout=5000, port=port=49326, 
localAddress=localAddress=127.0.0.1}
at 
jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(Unknown Source)

Caused by: java.io.IOException: Cannot run program 
"/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java":
 error=2, No such file or directory
at java.base/java.lang.ProcessBuilder.start(Unknown Source)

The path is as you indicate so either JShell is building the path or 
ProcessBuilder is. If the tool did it then it would seem to make things easier 
for the code using it. I wasn’t even remembering there was a java.home 
property. Runtime exec does not seem to do this.

Also if you just copy the command in you get…

error: No file system provider is available to handle this file: 
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app/halfpipe.jar

It seems there is some special sauce jlink provides so this is now definitely 
not possible. As Kevin Rushforth said.

Re: jpackage current status

[Michael Hall]

> 
> now you can build runtime that has the tools like I do here:
> 
>> $JDK_HOME/bin/jlink --bind-services --output mods.runtime --add-modules 
>> me.mymodule --module-path '../input-mods/mods'
> (../input-mods/mods has my app in me.mymodule)
> 
> then in app you can find any of the tools by using 
> System.getProperty("java.home") and looking in "bin" subdir.
> 
> So in the app you can refer to any of the tools by their full path.
> 
> My proposed addition of --jlink-options jpackage option would only make the 
> first step unnecessary.
> 

Seems like this would work if users were aware they needed to build the path. I 
could of sworn though that there were occasions where I successfully just 
created and copied in commands. I was wondering if there were some way in the 
native launcher to have the bin directory included in the paths searched by the 
launched java task. Maybe not. I just thought this used to work.

Re: jpackage current status

[Michael Hall]

> On Feb 24, 2020, at 2:59 PM, Kevin Rushforth  
> wrote:
> 
> 
> 
> On 2/24/2020 12:31 PM, Michael Hall wrote:
>> 
>>> On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:
>>> 
>>> 
>>> 
>>>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
>>>> wrote:
>>>> 
>>>> Since your ToolProvider-based program doesn't explicitly require 
>>>> jdk.incubator.jpackage, it won't be in the module graph. It should work 
>>>> fine if you run with:
>>>> 
>>>> $ java --add-modules jdk.incubator.jpackage ...
>>>> 
>>> I’m not understanding the module subtleties yet but yes that does work 
>>> command line. Other than -add-modules into the runtime are there any 
>>> special considerations for using it from an application?
>> Ah, the obvious. Same solution for application also works. I can 
>> programmatically invoke jpackage with this.
> 
> Good.
> 
>>> I am still wondering for the application embedded runtime exec not finding 
>>> linked native commands if this is expected not to work or is considered an 
>>> issue?
>>> 
>> This remains a question for me. Should Runtime exec find the native commands 
>> included with an application embedded JRE? It currently doesn’t seem to on 
>> OS X.
> 
> Unless that JRE's bin directory is in your PATH, I wouldn't expect it to find 
> it.
> 
OK, ToolProvider seems like it would be a preferred api. But unless someone 
figures out how to get the bin directory searched I wouldn’t see any point in 
having native commands included ever. 
Maybe the enhancement Andy mentioned for this a while back might address this?
A thought. I now have no need to.

Re: jpackage current status

[Michael Hall]

> On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
>> wrote:
>> 
>> Since your ToolProvider-based program doesn't explicitly require 
>> jdk.incubator.jpackage, it won't be in the module graph. It should work fine 
>> if you run with:
>> 
>> $ java --add-modules jdk.incubator.jpackage ...
>> 
> 
> I’m not understanding the module subtleties yet but yes that does work 
> command line. Other than -add-modules into the runtime are there any special 
> considerations for using it from an application?

Ah, the obvious. Same solution for application also works. I can 
programmatically invoke jpackage with this. 

> 
> I am still wondering for the application embedded runtime exec not finding 
> linked native commands if this is expected not to work or is considered an 
> issue?
> 

This remains a question for me. Should Runtime exec find the native commands 
included with an application embedded JRE? It currently doesn’t seem to on OS X.

Re: jpackage current status

[Michael Hall]

> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
> wrote:
> 
> Since your ToolProvider-based program doesn't explicitly require 
> jdk.incubator.jpackage, it won't be in the module graph. It should work fine 
> if you run with:
> 
> $ java --add-modules jdk.incubator.jpackage ...
> 

I’m not understanding the module subtleties yet but yes that does work command 
line. Other than -add-modules into the runtime are there any special 
considerations for using it from an application?

I am still wondering for the application embedded runtime exec not finding 
linked native commands if this is expected not to work or is considered an 
issue?

Thanks for the command line solution.

Re: jpackage current status

[Michael Hall]

> On Feb 24, 2020, at 11:16 AM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 24, 2020, at 11:12 AM, Andy Herrick > <mailto:andy.herr...@oracle.com>> wrote:
>> 
>> We have no problem invoking jpackage through the tool provider interface in 
>> all of our test cases.
>> 
>> In previous emails you described using a hybrid jdk13/jdk14 jdk. Can you 
>> explain what exactly you are using ?
>> 
>> /Andy
> 
> I was wondering what you had for tests. 
> Currently I have the latest ea or release candidate installed. I temporarily 
> had a jdk13 installed due to issues with Eclipse when I switched to that. 
> 
> java -version
> openjdk version "14" 2020-03-17
> OpenJDK Runtime Environment (build 14+36-1461)
> OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

Mac OS 10.14.6
On OS X you install the JDK by adding it to the JavaVirtualMachines directory. 

ls -l /Library/Java/JavaVirtualMachines
total 0
drwxr-xr-x  3 mjh  wheel   96 Dec 14  2018 jdk-11.0.1.jdk
drwxr-xr-x  4 mjh  wheel  128 Dec 15  2018 jdk-12.jdk
drwxr-xr-x@ 3 mjh  wheel   96 Apr 19  2019 jdk-13.jdk
drwxr-xr-x@ 3 mjh  staff   96 Feb  6 15:49 jdk-14.jdk
drwxr-xr-x  3 mjh  wheel   96 Sep 22  2017 jdk-9.jdk
drwxr-xr-x  3 mjh  wheel   96 May 16  2017 jdk1.8.0_131.jdk


Eclipse is now configured to use the jdk-13
Default should be the latest, now the jdk-14.

/usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home

Re: jpackage current status

[Michael Hall]

> On Feb 24, 2020, at 11:12 AM, Andy Herrick  wrote:
> 
> We have no problem invoking jpackage through the tool provider interface in 
> all of our test cases.
> 
> In previous emails you described using a hybrid jdk13/jdk14 jdk. Can you 
> explain what exactly you are using ?
> 
> /Andy

I was wondering what you had for tests. 
Currently I have the latest ea or release candidate installed. I temporarily 
had a jdk13 installed due to issues with Eclipse when I switched to that. 

java -version
openjdk version "14" 2020-03-17
OpenJDK Runtime Environment (build 14+36-1461)
OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)