Getting the JVM on a machine may or may not be a hurdle.
This was/is one of Java's mistakes. It's always been oddly hostile to JVM bundling, although some projects do so anyway (e.g. Jira). More generally, Java makes the mistake of making itself known to the user. The user is expected to install a JVM, rather than one being bundled with the application, and they're then expected to ensure it updates itself appropriately, complete with an annoying taskbar icon and always-resident auto-updater (on Windows, that is).
The user shouldn't even know the word 'Java'. Applications written in Pascal, for instance, are just applications. The user isn't made aware of the technology used.
Especially unfortunate considering that, as far as I can tell, JavaFX is really a pretty good GUI toolkit (I've only dabbled). Perhaps things will change as ahead-of-time compilation for Java becomes more mainstream.
Perhaps things will change as ahead-of-time compilation for Java becomes more mainstream
I understand JIT compilation is pretty advanced these days. Wouldn't this go against it? Or maybe the approach can be mixed, but if so, you'd still need the runtime environment ("the JVM").
A mixed approach can be done, yes. If dynamic classloading is needed, you need to bundle a JIT as well (or at least a traditional interpreter). Excelsior JET has used this hybrid approach for years. [0] I imagine it should be possible to omit the JIT if it can be determined that it's not needed.
If you ever try to write a bash script that calls a Java program in a tight loop, you'll know the limitations of a fat interpreting runtime with JIT compilation. Another relevant use case is the Stateless Lambda server-side architecture.
I believe Java (OpenJDK at least) is slow to start even if you disable the JIT and go with pure interpretation, and even if you disable runtime bytecode verification. It's just generally heavyweight and slow to get off the ground.
I imagine JIT compilation should help with this, as you suggest.
Since Java 8, there are two ways to build a binary: the javapackager tool, and the Ant JavaFX tasks (with the OpenJDK, install the openjfx package). It'll include the JRE [~50MB], and there are pros and cons with that obviously.
Comments
This was/is one of Java's mistakes. It's always been oddly hostile to JVM bundling, although some projects do so anyway (e.g. Jira). More generally, Java makes the mistake of making itself known to the user. The user is expected to install a JVM, rather than one being bundled with the application, and they're then expected to ensure it updates itself appropriately, complete with an annoying taskbar icon and always-resident auto-updater (on Windows, that is).
The user shouldn't even know the word 'Java'. Applications written in Pascal, for instance, are just applications. The user isn't made aware of the technology used.
Especially unfortunate considering that, as far as I can tell, JavaFX is really a pretty good GUI toolkit (I've only dabbled). Perhaps things will change as ahead-of-time compilation for Java becomes more mainstream.
They (Oracle and Java) are going the other direction on this. Jigsaw helped with JDK bundling. IntelliJ bundles its own distribution.
Excellent, I see I'm behind the times.
I understand JIT compilation is pretty advanced these days. Wouldn't this go against it? Or maybe the approach can be mixed, but if so, you'd still need the runtime environment ("the JVM").
A mixed approach can be done, yes. If dynamic classloading is needed, you need to bundle a JIT as well (or at least a traditional interpreter). Excelsior JET has used this hybrid approach for years. [0] I imagine it should be possible to omit the JIT if it can be determined that it's not needed.
[0] https://en.wikipedia.org/wiki/Excelsior_JET
If you ever try to write a bash script that calls a Java program in a tight loop, you'll know the limitations of a fat interpreting runtime with JIT compilation. Another relevant use case is the Stateless Lambda server-side architecture.
I believe Java (OpenJDK at least) is slow to start even if you disable the JIT and go with pure interpretation, and even if you disable runtime bytecode verification. It's just generally heavyweight and slow to get off the ground.
I imagine JIT compilation should help with this, as you suggest.
Oops, too late to edit, but I meant ahead-of-time compilation should help with this
Since Java 8, there are two ways to build a binary: the javapackager tool, and the Ant JavaFX tasks (with the OpenJDK, install the openjfx package). It'll include the JRE [~50MB], and there are pros and cons with that obviously.