> On Aug 8, 2015, at 5:16 PM, Scott Palmer <swpal...@gmail.com> wrote: > > I’m using the JavaFX gradle plugin to build a very simple application with > the new java packager and I’ve noticed a problem with the embedded JRE, at > least on OS X. > > Specifically, the ‘bin’ folder is missing from the embedded JRE, presumably > because the embedded launcher replaces it.
We deliberately strip that folder from the package. The functionality provided by the launcher is not equivalent and is only sufficient to support application launch. The goal is to have a JRE embedded just for the application, and leaving the bin folder leaves entry points for non-embeded use of the JRE. > However my application (and many others) needs to launch a new java process. > Part of the reason for doing so is so it can be launched with new JVM options > that are determined at runtime. For example modifying the java.library.dir > after finding “plugins” that have native code. > > Now it fails when running from the app bundle (works fine from a command > line). The problems is that it fails to launch a new ‘java’ process because > it expects to find 'bin/java' in the JRE folder. > > What is the solution? It's not easy, since this is functionality that is deliberately removed in the name of security. You could copy the .../bin/java file somewhere else prior to packaging and then copy it back into place after packaging, but that would be platform specific. > > Since I’m using Gradle, I’m thinking I could tweak things to copy the JRE bin > folder into the xxxx.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/ > folder, This would be very difficult to accomplish with the current gradle plugin. It's an unconventional step and hence the plugin makes unconventional stuff difficult unless hand wired soup to nuts. > but really the javapackager should have an option to include the “full” JRE. I haven't seen how the bugs.openjdk.java.net <http://bugs.openjdk.java.net/> transition has affectied it, but in the JIRA days I would say open a JIRA and we can add it to our feature queue. But this would have an additional step of going through a security audit (since the removal was deliberate for security) and the security engineers may not be cool with it (then again, if it is a non default option they may accept it), so it's not a slam dunk. > > Or perhaps we need a new API in Java 9 to support launching a new Java > process? > Officially it's not too late to get new features such as this into the 9.0 release, but unless it is related to the module system and making it work somehow my thoughts are that it won't get accepted into 9.0. > > Regards, > > Scott > >
