I’m only interested in macOS universal applications. I don’t see a need for
multi-OS applications.
The shared libraries do not need to be merged as the runtime is not itself
universal, only the launcher is.
The launcher finds the appropriate single-architecture runtime and launches it.
> On Ma
Alan Snyder wrote on 7. Mar 2024 22:39 (GMT +01:00):
> That could be done, but it would require more work with no obvious
> benefit.
>
> Only the Java launcher needs to be universal from the perspective of the
> OS.
it’s however not only the exetables. You have also the shared libraries,
possib
OK. I didn’t follow exactly what you’re doing. So I don’t know what would be
extra. I also assume it wouldn’t address any other architecture specific parts
of the jdk that you mentioned.
How are you planning on replacing the executables and getting valid signed
applications? I think it could be
That could be done, but it would require more work with no obvious benefit.
Only the Java launcher needs to be universal from the perspective of the OS.
> On Mar 7, 2024, at 1:24 PM, Michael Hall wrote:
>
> Not directly in response to your prior. But curious, are you doing something
> like
Not directly in response to your prior. But curious, are you doing something
like described here?
https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary
If not why not?
It indicates
> For universal binaries, the system prefers to execute the slice that is
>
As mentioned in a previous message, I am creating universal macOS bundled
applications by including two Java runtimes in the application bundle, one for
arm and one for x86. The primary disadvantage of universal applications is
their size. For Java applications, there is an obvious opportunity t
