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