Hi Alexey, Sorry for the late reply (I was inactive the last couple of days).
I feel free to comment w.r.t. the 2 issues which seem related > [1] https://bugs.openjdk.org/browse/JDK-8371438 To me, it seems best to go with Option 2, which would make "--mac-sign" option redundant. * Using "--mac-sign" with other options could inform about redundant option * Using "--mac-sign" option only should throw error I have to admit, the *old* behavior was very handy 🙈 > [2] https://bugs.openjdk.org/browse/JDK-8371440 Error instead of warning makes sense to me 👍 Both changes make the jpackage process very explicit and clear. Thanks, -- Daniel > > - Alexey > > On 11/6/2025 5:51 AM, Daniel Peintner wrote: > > Alexey, all, > > Thank you very much for your help. > I still have issues making it to work, and I shared logs privately. > > Anyhow, some general comments/suggestions. > > You are right, with JDK21 it was enough to state "--mac-sign"option, and it > picked the (only/correct) certificate (in my case). > > As I understand, with JDK25 this is no longer the case. I don't want to argue > whether the *old* or *new* way is preferred. However, it is a breaking change. > Hence, what I may suggest, though, is that it throw errors if the expected > information (i.e., "--mac-signing-key-user-name") is missing. Otherwise, a > developer doesn't know that there is a problem. > > The same goes to situations when it is not unique which certificate to pick. > You pointed me to [1] which fixes the problem that I can find the certificate > with *partial* information without the need to specify the full > --mac-signing-key-user-name. > In situations where there are more matches, I would argue the process should > fail again with an error message hinting the problem (e.g., certificate not > uniquely identifiable). Looking at [2] I don't think this is the case. > > Thank you very much for your continuous support! > > -- Daniel > > [1] https://bugs.openjdk.org/browse/JDK-8371094 > [2] > https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a > > > > On Wed, Nov 5, 2025 at 7:31 PM Alexey Semenyuk <[email protected]> > wrote: >> >> Daniel, >> >> I've commented on the logs you shared privately. Adding some thoughts to the >> mail list. >> >> jpackage configuration at [1] is missing "--mac-signing-key-user-name" or >> "--mac-app-image-sign-identity" option. I noted it the private email as well. >> At first I assumed it was a mistake, but then I came across an old thread >> about the very same jpackage issue at [2] where you state that "--mac-sign" >> option is sufficient to make jpackage find the signing identity. So this is >> intentional. >> >> jdk25 jpackage will not look up for the signing identity unless >> "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option is >> specified. I'm surprised it did in older releases. >> >> For the sake of backward compatibility we can restore this behavior. But I >> think jpackage should exit with an error if the "--mac-sign" option is >> specified, but neither "--mac-signing-key-user-name" nor >> "--mac-app-image-sign-identity" is. The old behavior, when without these >> options jpackage picked the first available certificate with the common name >> starting with "Developer ID Application: " substring is not secure. It >> literally tells jpackage to pick any certificate without any filtering. If >> there is only one such certificate installed and it gets replaced, you will >> not even notice that your app is signed with a different certificate. >> >> I suggest you add "--mac-signing-key-user-name" or >> "--mac-app-image-sign-identity" option to jpackage command line at [1] to >> make it work. >> >> [1] >> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151 >> [2] https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080291.html >> >> - Alexey >> >> On 11/5/2025 4:16 AM, Daniel Peintner wrote: >> >> Hi Alexey, >> >> Thank you for your reply. >> >>> Does the warning message resembles the one at [1]? >> >> >> Yes, exactly. >> >>> >>> I think your evaluation that the step 1 failed is correct. I'd suggest >>> adding "--verbose" option to the step 1 command line to get more details. >> >> >> I updated a demo/test project to demonstrate the problem. You can now also >> try it yourself. >> https://github.com/danielpeintner/Java11Test/tree/non-modular >> >> There you can also find the 3 jpackage commands I use >> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151 >> >> W.r.t. sharing the logs file. I will send them to you *privately*. I quickly >> scanned them and I would rather not have them on the reflector. >> >> The weird thing is, that the difference seems to happen in step 1. Anyhow, >> running these commands the difference is also somehow in step 2 where >> * JDK21 makes popping up a dialog which asks me whether I want to allow >> access to my keys >> * JDK25 does not need any interaction >> >> I hope this helps to find the "difference". >> >> Thanks, >> >> -- Daniel >> >> >> >> >>> >>> >>> [1] >>> https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85 >>> >>> - Alexey >>> >>> On 11/4/2025 12:32 PM, Daniel Peintner wrote: >>> >>> Hi Alexey, all, >>> >>> I nailed down the problem to the following, which seems to differ between >>> JDK25 and JDK21. >>> Maybe this helps to reproduce the issue. >>> >>> jpackage is called 3 times in my process >>> >>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage >>> --type app-image --input >>> /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib >>> --main-jar myPROJECT-25.11.03.jar --main-class >>> eu.my_company.myproject.Launcher --dest >>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage --name myPROJECT >>> --app-version 25.11.03 --runtime-image >>> /Users/daniel/Documents/GitHub/myPROJECT/build/jre --java-options >>> --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED >>> --java-options --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED >>> --java-options >>> --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED >>> --java-options >>> --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED >>> --java-options >>> --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED >>> --java-options --add-exports=java.management/javax.management=ALL-UNNAMED >>> --java-options >>> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>> --java-options --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED >>> --icon src/main/deploy/package/macosx/myPROJECT.icns >>> --mac-package-identifier eu.my-company.myproject --mac-sign >>> >>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage >>> --type pkg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage >>> --name myPROJECT --app-version 25.11.03 --app-image >>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app >>> --file-associations src/main/resources/associations.properties >>> --app-version 25.11.03 --vendor "My Company" --copyright "My Company" >>> --mac-sign >>> >>> /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage >>> --type dmg --dest /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage >>> --name myPROJECT --app-version 25.11.03 --app-image >>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app >>> --file-associations src/main/resources/associations.properties >>> --app-version 25.11.03 --vendor "My Company" --copyright "My Company" >>> --mac-sign >>> >>> >>> First it creates the app-image and afterwards it creates pkg and dmg and >>> signs it. >>> >>> As you can see in the 3 commands, it uses JDK21. >>> Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after step 2 already >>> with the following message in German >>> >>> Warnung: Nicht signiertes app-image wird zum Erstellen von signiertem pkg >>> verwendet. >>> >>> It translates to something like: it tries to sign pkg and complains that >>> the app-image is not signed. >>> Hence, somehow step 1 failed already but does not show any error/warning. >>> >>> Please let me know whether the above helps to reproduce the issue. >>> >>> Thanks, >>> >>> -- Daniel >>> >>> >>> >>> On Tue, Nov 4, 2025 at 4:01 PM Daniel Peintner <[email protected]> >>> wrote: >>>> >>>> Hi Alexey, >>>> >>>> Thank you for your reply. >>>> I am using the badass runtime plugin which calls jpackage under the hood. >>>> >>>> While trying to create an example project, I noticed that there were some >>>> changes >>>> '--mac-package-identifier' needs to go into imageOptions and not >>>> installerOptions. >>>> see >>>> https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385 >>>> >>>> That fixed the problem with jpackage. Anyhow, it still does not work with >>>> JDK25 and macOS signing. >>>> Using the JDK25 seems to need additional options (compared to JDK21). >>>> >>>> With JDK25 and --mac-sign the process no longer opens the KeyChain access >>>> and asks for the credentials. Hence, the image itself is no longer signed >>>> which matches with what I see on the debug console >>>> "non signed app-image used to sign dmg" ... freely translated into >>>> English since I see the German version only >>>> >>>> Therefore, apple's notary service says invalid with the logs like "The >>>> binary is not signed with a valid Developer ID certificate". >>>> >>>> Using the *same* gradle file, switching to JDK21 works without any issues >>>> again. >>>> I will try to investigate further. >>>> >>>> Thanks, >>>> >>>> -- Daniel >>>> >>>> >>>> >>>> >>>> On Mon, Nov 3, 2025 at 7:30 PM Alexey Semenyuk >>>> <[email protected]> wrote: >>>>> >>>>> Hi Daniel, >>>>> >>>>> I can not reproduce the issue you experience with jdk25.0.1: >>>>> >>>>> --- >>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output >>>>> --type app-image --main-jar hello.jar --main-class >>>>> com.my_domain.project.Hello --mac-package-identifier com.my-domain.project >>>>> $ echo $? >>>>> 0 >>>>> --- >>>>> >>>>> If I run the same command line without ` --mac-package-identifier` option >>>>> it fails as expected: >>>>> --- >>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output >>>>> --type app-image --main-jar hello.jar --main-class >>>>> com.my_domain.project.Hello >>>>> Bundler Mac Application Image skipped because of a configuration problem: >>>>> invalid mac bundle identifier [com.my_domain.project]. >>>>> Advice to fix: specify identifier with "--mac-package-identifier". >>>>> --- >>>>> >>>>> The same failure for `--mac-package-identifier com.my_domain.project` >>>>> (with the underscore): >>>>> --- >>>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage --input input --dest output >>>>> --type app-image --main-jar hello.jar --main-class >>>>> com.my_domain.project.Hello --mac-package-identifier com.my_domain.project >>>>> Bundler Mac Application Image skipped because of a configuration problem: >>>>> invalid mac bundle identifier [com.my_domain.project]. >>>>> Advice to fix: specify identifier with "--mac-package-identifier". >>>>> --- >>>>> >>>>> Any chance you accidentally put the string with the underscore instead of >>>>> the hyphen as a value of the `--mac-package-identifier` option on your >>>>> command line? >>>>> >>>>> - Alexey >>>>> >>>>> On 11/3/2025 11:43 AM, Daniel Peintner wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am about to switch a JavaFX project from JDK21 to JDK25 and I noticed a >>>>> problem when running jpackage. >>>>> >>>>> My domain has a hyphen, like in www.my-domain.com >>>>> Hence, my Java package reads like this: com.my_domain.project >>>>> Note: hyphen becomes underscore. >>>>> >>>>> Running vanilla jpackage in JDK21 complained with >>>>> Invalid Mac-Bundle-ID [com.my_domain.project] >>>>> due to the *invalid* underscore and suggests me to use >>>>> "--mac-package-identifier" >>>>> >>>>> Hence, I added --mac-package-identifier com.my-domain.project (with the >>>>> hyphen again) >>>>> All good so far. >>>>> >>>>> Running the same code with JDK25 with the above settings shows the error >>>>> message again >>>>> Invalid Mac-Bundle-ID [com.my_domain.project] >>>>> >>>>> I can add any argument to --mac-package-identifier >>>>> It seems it is simply not taken into account. >>>>> >>>>> I am using JDK 25.0.1 >>>>> >>>>> Is this a known issue with JDK25 and jpackage? >>>>> Is there any other way to make jpackage work? >>>>> >>>>> Thanks, >>>>> >>>>> -- Daniel >>>>> >>>>> >>>>> >>> >> >
