4 ms·

At least the MacOS binaries from Oracle are not packaged in a user-friendly manner. You just get a zip file containing JAVA_HOME, and it's up to the user to kno

by tjohns 7y ago

At least the MacOS binaries from Oracle are not packaged in a user-friendly manner. You just get a zip file containing JAVA_HOME, and it's up to the user to know what to do with this. Apple requires you to copy this to a very specific, deeply nested, hidden system directory. That's definitely not something I could ask an end user to deal with. After the bait and switch with the licensing for the original Java distribution, I'm not comfortable downloading anything from Oracle anyway. It's just too risky.

carimura 7y ago
What requirement does Apple put on the JDK location? All of mine are in ~/lib/* and are easy to manage. JENV for bonus points. Definitely not a double-click-install experience, but not hard to figure out for anyone with a bit of terminal experience.
- tjohns 7y ago
  If you want it to be recognized by the system as a valid runtime for Java apps, I believe it needs to be in /Library/Java/JavaVirtualMachines/jdk${VERSION}.jdk/Contents/Home/.
pron 7y ago
The JDK requires no installation, and the concept of a "desktop system JRE" is no longer recommended; in fact, a JRE is no longer shipped. The recommended practice is for developers to bundle a custom, minimized version of the runtime with their application (using jlink). End users shouldn't install any Java runtime anymore. > After the bait and switch with the licensing for the original Java distribution The product known as OracleJDK used to be part free, part commercial, based on which features you used. JRE downloads also used to contain that annoying search toolbar. What we at Oracle have done is completely open-source the JDK, for the first time in its history, and release it under two licenses: a free license, and a license for those who wish to buy support. There is a large clear warning on each download page guiding people to the distribution they need. I think most people agree that this is a very welcome change, and I see no bait and switch.
- tjohns 7y ago
  I know desktop system JRE's aren't recommended any more, but there's still plenty of apps out there that require them. I literally ran into this last week. I am glad to hear the toolbar on the JRE is gone, and I'm glad there's a prominent notice on the download pages - but there's effectively no free official standalone JRE for commercial use anymore.
  - pron 7y ago
    That's because a system JRE is the old way of doing things -- and moving away from that wasn't arbitrary; desktops are encouraging app stores, and servers are using containers -- and we want our OpenJDK developers (I'm one of those) to focus on the new way of doing things. Oracle doesn't have control over an ecosystem that could generate billions, like Google with Android or Apple with iOS, so to pay the hundreds of full-time developers who develop OpenJDK, we charge those who want to do things the old way for support. So if you don't want to switch to the new way of doing things, you have a few options: * Download a JRE with an installer from someone else who builds and distributes it; I don't know about certified distributions, but I think Adopt ships something JRE-like. * Buy support from Oracle (and help fund OpenJDK's development). * Build a JRE yourself from the JDK and package it with an installer. I think that's reasonable.
- vbezhenar 7y ago
  Without installation on Windows `Preferences.systemRoot();` writes bunch of log errors in stderr. It tries to create HLKM\Software\JavaSoft\Prefs. Installer creates that registry node, so it works just fine after that. I don't know if it's a bug or intended behaviour.
  - pron 7y ago
    Which version are you using? This could be this issue[1], fixed in 9. [1]: https://bugs.openjdk.java.net/browse/JDK-8139507 https://bugs.openjdk.java.net/browse/JDK-8139507
    - deleted 7y ago
chrisseaton 7y ago
> 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.
- tjohns 7y ago
  > 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.
  - chrisseaton 7y ago
    I'd argue that you're doing this all at too low-level - users shouldn't have to see JAR files - they don't know what those are. You should encapsulate the JAR and the JRE in a package.
    - zapzupnz 7y ago
      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.

by tjohns 7y ago

carimura 7y ago

What requirement does Apple put on the JDK location? All of mine are in ~/lib/* and are easy to manage. JENV for bonus points. Definitely not a double-click-install experience, but not hard to figure out for anyone with a bit of terminal experience.

tjohns 7y ago
If you want it to be recognized by the system as a valid runtime for Java apps, I believe it needs to be in /Library/Java/JavaVirtualMachines/jdk${VERSION}.jdk/Contents/Home/.

pron 7y ago

The JDK requires no installation, and the concept of a "desktop system JRE" is no longer recommended; in fact, a JRE is no longer shipped. The recommended practice is for developers to bundle a custom, minimized version of the runtime with their application (using jlink). End users shouldn't install any Java runtime anymore. > After the bait and switch with the licensing for the original Java distribution The product known as OracleJDK used to be part free, part commercial, based on which features you used. JRE downloads also used to contain that annoying search toolbar. What we at Oracle have done is completely open-source the JDK, for the first time in its history, and release it under two licenses: a free license, and a license for those who wish to buy support. There is a large clear warning on each download page guiding people to the distribution they need. I think most people agree that this is a very welcome change, and I see no bait and switch.

tjohns 7y ago
I know desktop system JRE's aren't recommended any more, but there's still plenty of apps out there that require them. I literally ran into this last week. I am glad to hear the toolbar on the JRE is gone, and I'm glad there's a prominent notice on the download pages - but there's effectively no free official standalone JRE for commercial use anymore.
- pron 7y ago
  That's because a system JRE is the old way of doing things -- and moving away from that wasn't arbitrary; desktops are encouraging app stores, and servers are using containers -- and we want our OpenJDK developers (I'm one of those) to focus on the new way of doing things. Oracle doesn't have control over an ecosystem that could generate billions, like Google with Android or Apple with iOS, so to pay the hundreds of full-time developers who develop OpenJDK, we charge those who want to do things the old way for support. So if you don't want to switch to the new way of doing things, you have a few options: * Download a JRE with an installer from someone else who builds and distributes it; I don't know about certified distributions, but I think Adopt ships something JRE-like. * Buy support from Oracle (and help fund OpenJDK's development). * Build a JRE yourself from the JDK and package it with an installer. I think that's reasonable.
vbezhenar 7y ago
Without installation on Windows `Preferences.systemRoot();` writes bunch of log errors in stderr. It tries to create HLKM\Software\JavaSoft\Prefs. Installer creates that registry node, so it works just fine after that. I don't know if it's a bug or intended behaviour.
- pron 7y ago
  Which version are you using? This could be this issue[1], fixed in 9. [1]: https://bugs.openjdk.java.net/browse/JDK-8139507 https://bugs.openjdk.java.net/browse/JDK-8139507
  - deleted 7y ago

chrisseaton 7y ago

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

tjohns 7y ago
> 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.
- chrisseaton 7y ago
  I'd argue that you're doing this all at too low-level - users shouldn't have to see JAR files - they don't know what those are. You should encapsulate the JAR and the JRE in a package.
  - zapzupnz 7y ago
    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.