OP's joke is to maintain that JRE is Java Runtime Environment. In that context, a tech support complaint about missing that dependency is something you would not expect to see on hacker news.
> You are saying that their JRE build is JDK but 4x smaller?
I am saying they're distributing a runtime image and calling it a JRE, even though it isn't (i.e. it isn't centrally managed). Also, the IBM team that builds the Adopt distribution are not involved with OpenJDK and are a bit confused about the project, but, to be fair, even competent vendors, like Azul, provide runtime packages that they've chosen to call (confusingly, IMO), JREs.
> So, you are saying that if someone discovers a security bug in Java/JVM 11.x (assume the latest official version), it is a better practice to update every application on servers instead of just pulling down newer JVM build and let package manager do the magic?
No. First, you could let the package manager do the update either way. An application vendor still has the option of sharing a runtime among apps; the point is that it is up to them. Second, you need to update all of your applications regularly regardless. They have security vulnerabilities, too. Instead of having different update mechanisms for different application components, each application will have one update mechanism of its own choosing.
> I bundled the JRE with my app so the users did not need to have Java installed.
Side note here: do you track security vulnerabilities of the shipped JRE and provide updates when it happens?
Too often, I've seen java applications shipping obsolete and vulnerable JRE. And in some cases, I've seen not consistent versions across a product line.
Also wasn't there some unknowns about the right to redistribute the Oracle JRE?
> This applies to java runetime client from Oracle. Which to most users is "java
You are late by a few years. There is no JRE anymore, you are supposed to either use a JDK (e.g. for development) or bundle a small, optimized version of the JDK specifically for your app (see jlink, jpackage for more information).
> 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.
It's a runtime, not a runtime environment. The common meaning of a JRE is some system-wide Java environment, that the user obtains from a third-party (Oracle) and installs on their machine, with a system-wide "current" Java version. That no longer exists.
It is true that if everyone understood the difference between a JRE and any other Java runtime, yet chose to call them all "JRE" and expect the meaning to be understood from context, insistence over proper terminology would have merely been pedantic, but that's not the situation. Discontinuing the JRE in favour of custom runtimes was a big change, and one that people still don't fully understand.
> That's the really big "IF" that the article is trying to address, I think.
Seriously? Java comes with most modern operating systems and is easy to install on the remainders. The article is about getting a dev environment set up beyond the JDK.
I meant that I was attempting to install and run the code from the article, which is written in JRuby+Java and depends on a couple of third-party Java libraries.
> so you're not required to have for example JRE or a .NET runtime installed
These days you are not required to have a JRE or .NET runtime installed. At least on the JRE side, it can be embedded in the executable - I assume .NET has something similar.
There has to be more to it than that, though. Perhaps it is the "easy" part you mentioned - I have no idea what's involved in building a greenfield java bytecode interpreter, for example.
reply