Re: slightly ot: java9 runtime images
Hi Tom, could you do this with File.deleteOnExit? Question is, can it delete jars on its own classpath... Werner On 14.05.2015 08:22, Tom Eugelink wrote: Unfortunately you cannot have the spawned JVM cleanup after itself, otherwise I could stop the initial JVM after it spawned the other.
Re: slightly ot: java9 runtime images
It tried every angle, including tempfile. Problem is that that the initial JVM creates the file, so it can consider it a temp file, for the spawned JVM it is an existing file. Tom On 15-5-2015 12:28, Werner Lehmann wrote: Hi Tom, could you do this with File.deleteOnExit? Question is, can it delete jars on its own classpath... Werner On 14.05.2015 08:22, Tom Eugelink wrote: Unfortunately you cannot have the spawned JVM cleanup after itself, otherwise I could stop the initial JVM after it spawned the other.
Re: slightly ot: java9 runtime images
Correct. I keep comparing to my appjar tool which, as said before, is a single jar containing all the other jars unmodified. When started through java -jar, it does the following: - Unpack itself to a temp directory. - Spawn a new JVM with a classpath referring to all the unpacked stuff. - The initial JVM is then going into monitor mode, waiting for the spawned JVM to terminate. - When the spawned JVM terminates, the initial JVM tries to clean up the temp directory. This works well enough, sometimes the cleanup is a problem with locks preventing deleting, and I'm not too happy that I have to run two JVMs, but that are small issues compared to just being able to release my application by copying a single jar (and not have issues with signed jars). Unfortunately you cannot have the spawned JVM cleanup after itself, otherwise I could stop the initial JVM after it spawned the other. I figure it should not be that hard to replace the unpack and cleanup logic with native code, and build an EXE that way, so I assumed javafx packager did that. Apparently not. Hmmm, this could of course be a great use case for Go. And about that Oracle Sales rep, well, you know, I contribute by making my spare time work available for free; I don't know any Oracle sales rep. Tom On 13-5-2015 19:09, Danno Ferrin wrote: I think what Tom was alluding to was an all in one executable that contains all the data in one file. What the Windows Application Image creates is a directory that contains all the jars, the JRE, and the executable that launches the whole setup. If an all in one executable is something you think will be generally valuable, please let you Oracle Sales rep know so they can pass it down to the PM group so we can get it on the radar. On May 13, 2015, at 4:19 AM, Benjamin Gudehus hasteb...@gmail.com mailto:hasteb...@gmail.com wrote: Hi Tom! I would really like to be able to generate such a standalone exe. With Danno's javafx-gradle Gradle plugin and with the java package API (com.oracle.tools.packager.Bundler from Java 8) it is possible to generate a standalone exe without installer (the bundler name is Windows Application Image). That's the first thing I noticed, when I tested it. Regards, Benjamin On Wed, May 13, 2015 at 11:43 AM, Tom Eugelink t...@tbee.org mailto:t...@tbee.org wrote: On 7-5-2015 15:52, Danno Ferrin wrote: It would be a major improvement (not only for JavaFX applications, but also standalone servers) if it would become possible to create a truly single distributable, without having to repack the jars. So either by automatic unpacking to a tmp and setting the classpath prior to stating java (cleaning up afterwards), or allowing jars-in-jars or jars-in-distributable. In 8u40 we added an option to install your application as service or daemon, so you can use the java packager to install your microsoervices. I've spent some time with the JavaFX packager (though the javafx-maven-plugin) and I am able to generate: - a distribution in the form of a lib directory and entry point jar - an exe msi that are both installers What I am not able to generate is an exe that can simply be started. Right now my distribution consist of an all-in-one jar (jars-in-a-jar) that can simply be started. The JRE is also simply copied (when not present), so there is no need to install anything, just copy and start. I would really like to be able to generate such a standalone exe. Is this a limitation of the plugin or the packager? Since the plugin seems to be very close to the packager, I'm thinking the latter. Tom
Re: slightly ot: java9 runtime images
On 7-5-2015 15:52, Danno Ferrin wrote: It would be a major improvement (not only for JavaFX applications, but also standalone servers) if it would become possible to create a truly single distributable, without having to repack the jars. So either by automatic unpacking to a tmp and setting the classpath prior to stating java (cleaning up afterwards), or allowing jars-in-jars or jars-in-distributable. In 8u40 we added an option to install your application as service or daemon, so you can use the java packager to install your microsoervices. I've spent some time with the JavaFX packager (though the javafx-maven-plugin) and I am able to generate: - a distribution in the form of a lib directory and entry point jar - an exe msi that are both installers What I am not able to generate is an exe that can simply be started. Right now my distribution consist of an all-in-one jar (jars-in-a-jar) that can simply be started. The JRE is also simply copied (when not present), so there is no need to install anything, just copy and start. I would really like to be able to generate such a standalone exe. Is this a limitation of the plugin or the packager? Since the plugin seems to be very close to the packager, I'm thinking the latter. Tom
Re: slightly ot: java9 runtime images
Hi Tom! I would really like to be able to generate such a standalone exe. With Danno's javafx-gradle Gradle plugin and with the java package API (com.oracle.tools.packager.Bundler from Java 8) it is possible to generate a standalone exe without installer (the bundler name is Windows Application Image). That's the first thing I noticed, when I tested it. Regards, Benjamin On Wed, May 13, 2015 at 11:43 AM, Tom Eugelink t...@tbee.org wrote: On 7-5-2015 15:52, Danno Ferrin wrote: It would be a major improvement (not only for JavaFX applications, but also standalone servers) if it would become possible to create a truly single distributable, without having to repack the jars. So either by automatic unpacking to a tmp and setting the classpath prior to stating java (cleaning up afterwards), or allowing jars-in-jars or jars-in-distributable. In 8u40 we added an option to install your application as service or daemon, so you can use the java packager to install your microsoervices. I've spent some time with the JavaFX packager (though the javafx-maven-plugin) and I am able to generate: - a distribution in the form of a lib directory and entry point jar - an exe msi that are both installers What I am not able to generate is an exe that can simply be started. Right now my distribution consist of an all-in-one jar (jars-in-a-jar) that can simply be started. The JRE is also simply copied (when not present), so there is no need to install anything, just copy and start. I would really like to be able to generate such a standalone exe. Is this a limitation of the plugin or the packager? Since the plugin seems to be very close to the packager, I'm thinking the latter. Tom
Re: slightly ot: java9 runtime images
I think what Tom was alluding to was an all in one executable that contains all the data in one file. What the Windows Application Image creates is a directory that contains all the jars, the JRE, and the executable that launches the whole setup. If an all in one executable is something you think will be generally valuable, please let you Oracle Sales rep know so they can pass it down to the PM group so we can get it on the radar. On May 13, 2015, at 4:19 AM, Benjamin Gudehus hasteb...@gmail.com wrote: Hi Tom! I would really like to be able to generate such a standalone exe. With Danno's javafx-gradle Gradle plugin and with the java package API (com.oracle.tools.packager.Bundler from Java 8) it is possible to generate a standalone exe without installer (the bundler name is Windows Application Image). That's the first thing I noticed, when I tested it. Regards, Benjamin On Wed, May 13, 2015 at 11:43 AM, Tom Eugelink t...@tbee.org mailto:t...@tbee.org wrote: On 7-5-2015 15:52, Danno Ferrin wrote: It would be a major improvement (not only for JavaFX applications, but also standalone servers) if it would become possible to create a truly single distributable, without having to repack the jars. So either by automatic unpacking to a tmp and setting the classpath prior to stating java (cleaning up afterwards), or allowing jars-in-jars or jars-in-distributable. In 8u40 we added an option to install your application as service or daemon, so you can use the java packager to install your microsoervices. I've spent some time with the JavaFX packager (though the javafx-maven-plugin) and I am able to generate: - a distribution in the form of a lib directory and entry point jar - an exe msi that are both installers What I am not able to generate is an exe that can simply be started. Right now my distribution consist of an all-in-one jar (jars-in-a-jar) that can simply be started. The JRE is also simply copied (when not present), so there is no need to install anything, just copy and start. I would really like to be able to generate such a standalone exe. Is this a limitation of the plugin or the packager? Since the plugin seems to be very close to the packager, I'm thinking the latter. Tom
Re: slightly ot: java9 runtime images
On 07.05.15 14:27, Tom Eugelink wrote: On 7-5-2015 02:15, Danno Ferrin wrote: You can already do some of that today with Java 8 and the Java Packager. You can create a file tree that can be zipped up that includes the runtime and all of the application files, as well as native installers for windows, linux, and mac that will install this file tree (or “image”). We haven’t announced many public plans for Java 9 yet (since many parts are still TBD) so I cannot comment on how jigsaw and java packager will integrate, but I would expect that they will work together in some fashion. From all the documentation I find, I understand that even though with Java packager you can create an executable including the (required parts of the) JVM, you still need to unpack and repack all the jars into a single jar. This has the problem of breaking signed jars. Classloader based solutions like onejar get into all kind of conflicts with possible other classloaders in the application. No this is not required - we are even packaging Equinox-OSGi-Applications who consist of 30 different jars. Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: slightly ot: java9 runtime images
[...] In 8u40 we added an option to install your application as service or daemon, so you can use the java packager to install your microsoervices. [offtopic] Interesting where is this documented - google did not show up any results? Do I get callbacks in my Java code to react on a shutdown request? Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: slightly ot: java9 runtime images
On May 7, 2015, at 6:27 AM, Tom Eugelink t...@tbee.org wrote: On 7-5-2015 02:15, Danno Ferrin wrote: You can already do some of that today with Java 8 and the Java Packager. You can create a file tree that can be zipped up that includes the runtime and all of the application files, as well as native installers for windows, linux, and mac that will install this file tree (or “image”). We haven’t announced many public plans for Java 9 yet (since many parts are still TBD) so I cannot comment on how jigsaw and java packager will integrate, but I would expect that they will work together in some fashion. From all the documentation I find, I understand that even though with Java packager you can create an executable including the (required parts of the) JVM, you still need to unpack and repack all the jars into a single jar. This has the problem of breaking signed jars. Classloader based solutions like onejar get into all kind of conflicts with possible other classloaders in the application. I don’t know where you got your information, it has never been the case for as long as i’ve used it and worked on it before my employ at Oracle that you have to rely on a single jar for Java Packager. Repacking jars is completely unneeded and the Java Packager takes the library jars you provide without alteration, preserving external signatures and structure essential to stuff like OSGi. In fact, you can provide assets that are not jars and you can set the class path to only include certain jars, no need to unpack jars at runtime. It would be a major improvement (not only for JavaFX applications, but also standalone servers) if it would become possible to create a truly single distributable, without having to repack the jars. So either by automatic unpacking to a tmp and setting the classpath prior to stating java (cleaning up afterwards), or allowing jars-in-jars or jars-in-distributable. In 8u40 we added an option to install your application as service or daemon, so you can use the java packager to install your microsoervices.
Re: slightly ot: java9 runtime images
On 7-5-2015 15:52, Danno Ferrin wrote: I don’t know where you got your information, it has never been the case for as long as i’ve used it and worked on it before my employ at Oracle that you have to rely on a single jar for Java Packager. Repacking jars is completely unneeded and the Java Packager takes the library jars you provide without alteration, preserving external signatures and structure essential to stuff like OSGi. In fact, you can provide assets that are not jars and you can set the class path to only include certain jars, no need to unpack jars at runtime. That is good to hear. It is hard to retrace all the sites I visited this morning, but this was one of them. http://java.dzone.com/articles/creating-executable-uber-jar%E2%80%99s Tom
Re: slightly ot: java9 runtime images
On 7-5-2015 16:44, Mike Hearn wrote: Do you actually need JAR signatures anyway? The JVM is bundled, it's not like you have to pass some system security policy beyond Gatekeeper/Windows code signing. Well, I remember the official Sun mail.jar being signed and causing headaches if it was repacked. But the newer mail.jar is no longer signed, so maybe it is less of an issue now than back when I wrote the appjar tool (unpack a jar-of-jar to a tmp folder). Time to update my knowledge then. Tom
Re: slightly ot: java9 runtime images
Do you actually need JAR signatures anyway? The JVM is bundled, it's not like you have to pass some system security policy beyond Gatekeeper/Windows code signing.
Re: slightly ot: java9 runtime images
I looked at the man pages, and it’s not there. That is strange because I remember working with the docs people to get them the info they needed. The best docs are from my JavaOne presentation: https://oracleus.activeevents.com/2014/connect/fileDownload/session/3B139AAF656DC1741328669FE873981E/CON2247_Ferrin-8u20%20packager.pdf https://oracleus.activeevents.com/2014/connect/fileDownload/session/3B139AAF656DC1741328669FE873981E/CON2247_Ferrin-8u20%20packager.pdf As far as java callbacks… the support is fairly basic at the moment. You own the JVM w/o a security sandbox so you can add standard shutdown hooks as well as other libraries that react to unix signals. Signals are non-standard as the current Java signal classes exist in sun.misc.*, hence they an internal API and will not be accessible in JDK 9 (without contortions). For windows a custom service executable is created. For Linux init.d scripts are added. For Mac launchd is used. On May 7, 2015, at 8:04 AM, Tom Schindl tom.schi...@bestsolution.at wrote: [...] In 8u40 we added an option to install your application as service or daemon, so you can use the java packager to install your microsoervices. [offtopic] Interesting where is this documented - google did not show up any results? Do I get callbacks in my Java code to react on a shutdown request? Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: slightly ot: java9 runtime images
On 7-5-2015 02:15, Danno Ferrin wrote: You can already do some of that today with Java 8 and the Java Packager. You can create a file tree that can be zipped up that includes the runtime and all of the application files, as well as native installers for windows, linux, and mac that will install this file tree (or “image”). We haven’t announced many public plans for Java 9 yet (since many parts are still TBD) so I cannot comment on how jigsaw and java packager will integrate, but I would expect that they will work together in some fashion. From all the documentation I find, I understand that even though with Java packager you can create an executable including the (required parts of the) JVM, you still need to unpack and repack all the jars into a single jar. This has the problem of breaking signed jars. Classloader based solutions like onejar get into all kind of conflicts with possible other classloaders in the application. It would be a major improvement (not only for JavaFX applications, but also standalone servers) if it would become possible to create a truly single distributable, without having to repack the jars. So either by automatic unpacking to a tmp and setting the classpath prior to stating java (cleaning up afterwards), or allowing jars-in-jars or jars-in-distributable. Just my 2 cents, Tom
slightly ot: java9 runtime images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. Sorry for asking it here, but I have too many lists I subscribed to and I don't want to join a new one just to ask this one question: I heard that java9 will (or might) make it possible to create a runtime image of an application consisting of all modules that it needs including parts of the standard library, and also the virtual machine. If what I've heard is right, what form will those images have? executable programs, or zip/tar/whatever archives containing all components, or native installers? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVSqYkAAoJEHb1CzgxXKwYEHIP/jLUVuLDZ7v73lupaTb8/eV3 m4/PhJYpTLS5pH1sa3tmIfrt45d8kEsFCEW9GNphu0U7NYVHRySO65i1Fr1T6DjK nzW3yJBIaJsC2RH0wsJuA8KIyvxbVwkQCtLS2p4Qqn0JI4FJuybz9ruSeWxbqpUh F99RFTCczHOlMfETOLq385ySCdZhFjLjcRCOeNCztHHr2UD6HEqDNxjMf3R4i37J lL1NZzN5CCNcbtOnxok9LqLNPHKhbVJQi46kQCBZCz14l9rioB5VTLJ+2XQF9iXr OYLvrI/5MqppzqSMFm2c2hBKF27QqiFKSOhR9cHoRlppCbr+aFccjvDPYqQ1GOom 07fx84hDo8EsyzgxVL/QdVHWdurxo6AoKTkVuYYAaXpkmvSQMqaHmkEt5yTnf+FU 4rH66DAx2sOkhYTOQmCYaV3ooX4gyO40CkEz23MjtaBTGm0GTZlObAAsIIihMVL6 VdWv9m29bxYLbVwuOlnI8FFMZg5kKK8ww5hrr8MrBCCohQ3xbdf8nD+KYq6Tb/CD E5ppAIblbiUPqxfCldeUXq79Gua4sKsuHIbhLYKXwY+NJ9HiZmGYHsigeNIUJg/H octepDQ9QNPELg74VbPqU5kNrzf8KKN76nhDB9O8AIRqz6XHMTmjV4i/7uAk6nyD BTNqknDDIrI0QbQJRaUx =x1GO -END PGP SIGNATURE-
Re: slightly ot: java9 runtime images
On May 6, 2015, at 5:39 PM, Michał Zegan webczat_...@poczta.onet.pl wrote: Hello. Sorry for asking it here, but I have too many lists I subscribed to and I don't want to join a new one just to ask this one question: I heard that java9 will (or might) make it possible to create a runtime image of an application consisting of all modules that it needs including parts of the standard library, and also the virtual machine. What you are describing is the Jigsaw project, which has been demoed at several JavaOnes. Some of the process bits can be found on this website: http://openjdk.java.net/projects/jigsaw/ http://openjdk.java.net/projects/jigsaw/ If what I've heard is right, what form will those images have? Right now it looks suspiciously similar to what a Java 8 runtime image looks like. But there are already some major differences. JEP 201 and JEP 220 cover most of those changes at the moment. executable programs, or zip/tar/whatever archives containing all components, or native installers? You can already do some of that today with Java 8 and the Java Packager. You can create a file tree that can be zipped up that includes the runtime and all of the application files, as well as native installers for windows, linux, and mac that will install this file tree (or “image”). We haven’t announced many public plans for Java 9 yet (since many parts are still TBD) so I cannot comment on how jigsaw and java packager will integrate, but I would expect that they will work together in some fashion. snipped PGP bits
