> it's up to the user to know what to do with this
Why are you asking your end-users to manually install your development dependencies, though? It's called the J D K for a reason. Ship a linked version of your application.
> Apple requires you to copy this to a very specific, deeply nested, hidden system directory.
This just isn't true - you can run Java from anywhere. It's just a tarball containing the binaries. Un-tar and run the binaries like you would any other program. I never 'install' Java on macOS.
> Why are you asking your end-users to manually install your development dependencies, though?
If you want to run a legacy desktop Java application (without bundled JRE - and yes, there's still plenty of these apps out there), MacOS will actually do the prompting for you.
And it takes you to the commercial JRE download page, which isn't something I'm willing to install. So the only reasonable option I could find as an end-user who wants a non license-encumbered JRE is to install OpenJDK.
> This just isn't true - you can run Java from anywhere. It's just a tarball containing the binaries. Un-tar and run the binaries like you would any other program. I never 'install' Java on macOS.
From the command line, of course that's true.
But if you double click on a .jar file from Finder, does MacOS find your JRE in a random directory? I was pretty sure that it doesn't do that.
One should but, as this has never been necessary on macOS, it would be highly unusual.
Java is considered a system-wide framework, even when installed by the user. macOS treats Java applications specially in order to provide them with special macOS-only functionality; for instance, when an application bundle is launched that requires the JRE, the system will open a notification informing the user that a JRE must be installed and provides a helpful link.
There is a further assumption that the version of Java that a user installs will also include a self-updater, ensuring that the user always has the latest version of Java installed to mitigate security issues from using old versions.
The recent modification of Java's licence doesn't seem sufficient impetus to change this behaviour on which all Java applications have depended since Mac OS X first released, one that even continued after Java was deprecated as a built-in installation option.
The reason Java is no longer a system-wide framework, and the assumption that it is has to change, has nothing to do with the recent shift from a semi-free/semi-paid JDK to a 100% free one, and everything to do with the fact that the entire software ecosystem has changed and Java must change with it. Desktop OSes encourage the app store model, and people deploy server applications in containers; neither of these is particularly hospitable to a system-wide runtime. The majority of both developers and end-users prefer a bundled deployment model that fits better with the current software environment (and also gives developer better control over their application's dependencies). If Oracle were to support popular deployment options as well as those that were popular years ago but some people still like, it would come at the expense of other things, like moving the platform forward.
Why are you asking your end-users to manually install your development dependencies, though? It's called the J D K for a reason. Ship a linked version of your application.
> Apple requires you to copy this to a very specific, deeply nested, hidden system directory.
This just isn't true - you can run Java from anywhere. It's just a tarball containing the binaries. Un-tar and run the binaries like you would any other program. I never 'install' Java on macOS.