Inconsistent results involving code signatures and bundles

I admit I am doing something unusual, and I would not be surprised if it didn't work. I am surprised, however, because after performing the equivalent operations on four bundles, all of the bundles work fine on macOS 15.6.1, but only two of them work on macOS 26.1 (beta 2). I don't know what causes the different outcomes.

What I am trying to do is get Java to pass the macOS 26 AppKit UI SDK linkage checking without having to rebuild the JDK using Xcode 26. Rebuilding works for the latest SDK, but it is very inconvenient and may not work for older JDKs. It usually takes a while before the JDK build team successfully transitions to a new Xcode release.

My approach is to use vtool to update the sdk version in the LC_BUILD_VERSION load command of $JAVA_HOME/bin/java, which is the launching executable for the JDK.

I performed this operation on four JDKs: 25, 21, 17, and 11. (I ran vtool on macOS 15.) It was completely successful on JDK 25 and 21. The JDK launches correctly on macOS 15 and macOS 26. On macOS 26, AppKit uses the new UI, which is the desired outcome. The JDK runs despite that fact that I signed the modified $JAVA_HOME/bin/java with my developer ID, which is inconsistent with the JDK bundle signature. (Redoing the bundle signing is part of the JDK build process; if that were necessary, I would stick with rebuilding the JDK.)

The operation was not successful on JDK 17 and 11. I noticed two problems, which are not obviously related.

  1. When vtool created the new version of the java program, it lost the tool definition.
$ vtool -show-build-version java
java:
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 11.1
   ntools 1
     tool LD
  version 609.8
$ vtool -set-build-version 1 10.0 26.0 -output a.out java
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/vtool warning: code signature will be invalid for a.out
$ vtool -show-build-version a.out
a.out:
Load command 22
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform MACOS
    minos 10.0
      sdk 26.0
   ntools 0

Adding back the tool definition didn't seem to matter.

  1. When I try to run the revised executable (in the context of the JDK bundle), it works on macOS 15, but on macOS 26, it is rejected as damaged. If I run the revised executable outside the JDK bundle, it runs (but fails because it can't find the rest of the JDK, which is expected).

In all cases, GateKeeper rejects the revised executable because it has not been notarized, but that doesn't seem to stop the program from executing.

Inconsistent results involving code signatures and bundles
 
 
Q