3 ms·

One setback with this release is that the javapackager tool, which made native installers that bundled the Java runtime, was removed (presumably because it depe

by gw 8y ago

One setback with this release is that the javapackager tool, which made native installers that bundled the Java runtime, was removed (presumably because it depended on JavaFX) and there is no replacement for it. One is being proposed at http://openjdk.java.net/jeps/343 http://openjdk.java.net/jeps/343 but I'm not sure when that is expected to be done.

the8472 8y ago
If your application doesn't do bytecode generation or instrumentation at runtime then the graal native image compiler might do the job too or even better. https://www.graalvm.org/docs/examples/native-list-dir/ https://www.graalvm.org/docs/examples/native-list-dir/
- xienze 8y ago
  > If your application doesn't do bytecode generation or instrumentation at runtime I believe it also has trouble with reflection involving class names that aren't effectively constant at compile-time. So with that and the other limitations, there's a whole lot you can't do. Hopefully they can resolve that.
  - calcifer 8y ago
    > reflection involving class names that aren't effectively constant at compile-time Can you give an example?
    - xienze 8y ago
      Sure, just about any project that has the concept of plugins. At runtime the code looks for plugin instances by searching for, e.g., META-INF/services/<interface_name> on the classpath. Inside that file (or files) you have implementation class names, which are collected and instantiated.
  - the8472 8y ago
    I don't think they intend to solve that because the cases that it can't handle are basically application servers, plugin-based applications and the like. They violate the closed world assumption which graal's native image builder relies on. Those are better served by a full JVM, optionally boiled down with jlink or with AOT compilation for faster startup, and the JEP that was mentioned upthread.
  - pjmlp 8y ago
    This limitation also exists in other languages that have reflection. In .NET Native and Lisp for example, you need to list code that should be kept around and not removed by the linker. It is not an easy problem to sort out in some kind of automatic way.
- hyperman1 8y ago
  Can graalvm do windows too?
- gw 8y ago
  It looks like that makes a native executable, not a package meant for end users. The javapackager tool actually built .exe, .app, .deb, and other OS-specific packages.
ptx 8y ago
You can replace it with separate components: * Run jlink manually (or scripted) to create the bundled runtime. * Create launcher executables with packr[1]. * Create the installer using whatever tools people normally use for native applications. NSIS[2] and WiX[3] are widely used. (I haven't gotten to this step yet myself.) [1] https://github.com/libgdx/packr https://github.com/libgdx/packr [2] http://nsis.sourceforge.net/ http://nsis.sourceforge.net/ [3] http://wixtoolset.org/ http://wixtoolset.org/
- jontro 8y ago
  I was positively surprised when I noticed how easy it is to create a windows installer using nsis from osx. makensis is cross platform and can be integrated easily in the build toolchain

by gw 8y ago

the8472 8y ago

If your application doesn't do bytecode generation or instrumentation at runtime then the graal native image compiler might do the job too or even better. https://www.graalvm.org/docs/examples/native-list-dir/ https://www.graalvm.org/docs/examples/native-list-dir/

xienze 8y ago
> If your application doesn't do bytecode generation or instrumentation at runtime I believe it also has trouble with reflection involving class names that aren't effectively constant at compile-time. So with that and the other limitations, there's a whole lot you can't do. Hopefully they can resolve that.
- calcifer 8y ago
  > reflection involving class names that aren't effectively constant at compile-time Can you give an example?
  - xienze 8y ago
    Sure, just about any project that has the concept of plugins. At runtime the code looks for plugin instances by searching for, e.g., META-INF/services/<interface_name> on the classpath. Inside that file (or files) you have implementation class names, which are collected and instantiated.
- the8472 8y ago
  I don't think they intend to solve that because the cases that it can't handle are basically application servers, plugin-based applications and the like. They violate the closed world assumption which graal's native image builder relies on. Those are better served by a full JVM, optionally boiled down with jlink or with AOT compilation for faster startup, and the JEP that was mentioned upthread.
- pjmlp 8y ago
  This limitation also exists in other languages that have reflection. In .NET Native and Lisp for example, you need to list code that should be kept around and not removed by the linker. It is not an easy problem to sort out in some kind of automatic way.
hyperman1 8y ago
Can graalvm do windows too?
gw 8y ago
It looks like that makes a native executable, not a package meant for end users. The javapackager tool actually built .exe, .app, .deb, and other OS-specific packages.

ptx 8y ago

You can replace it with separate components: * Run jlink manually (or scripted) to create the bundled runtime. * Create launcher executables with packr[1]. * Create the installer using whatever tools people normally use for native applications. NSIS[2] and WiX[3] are widely used. (I haven't gotten to this step yet myself.) [1] https://github.com/libgdx/packr https://github.com/libgdx/packr [2] http://nsis.sourceforge.net/ http://nsis.sourceforge.net/ [3] http://wixtoolset.org/ http://wixtoolset.org/

jontro 8y ago
I was positively surprised when I noticed how easy it is to create a windows installer using nsis from osx. makensis is cross platform and can be integrated easily in the build toolchain