... simply that you don't *want* jpackage's jdk to be in your path, you
don't want it to be the default, you *only* want it to run jpackage
*itself*, in create-image using --runtime-image pointing to your already
jlinked runtime image using your usual JDK; then in create-installer,
using --app-image to point to the image created in create-image. In all
other respects you build your application with your usual JDK, this one
is *just* for running jpackage, and only exists at all because jpackage
isn't ready to go in the JDK proper yet.
That's how it's working for me anyway. :-)
I wonder if it would be easier if, while we're in this packager gap, to
provide jpackage as a jlinked app image rather than a full jdk? Is that
possible?
--
Rachel
On 15/01/2019 16:04, Michael Hall wrote:
On Jan 15, 2019, at 9:18 AM, Rachel Greenham <rac...@strangenoises.org> wrote:
surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie:
emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, and
then it doesn't get in the way of anything else. When you want to use jpackage
invoke, directly, /opt/jdk-13/bin/jpackage, which is a path you can put in a
convenient system variable perhaps, or symlink it into your path somewhere.
--
Rachel
On 15/01/2019 12:09, Kustaa Nyholm wrote:
On 15 Jan 2019, at 12.57, Michael Hall <mik3h...@gmail.com> wrote:
Usually the latest jdk with the command would be the one you’d want?
Funnily enough, I wanted to quickly test something (jdeps) from the command
line,
and sure enough it evoked jdk-13 ea which is NOT what I want cause my main goal
is to move all my stuff to jdk-11 and stay with that for next 5 years or so.
For those who are not aware here is tip how to disable a jdk on MacOs:
cd /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/
sudo mv Info.plist Info.plist-disabled
i.e. just rename the Info.plist so that it cannot be found by the tools,
after that command line tools reverted to jdk-11.0.1
wrb Kusti
What advantage does this have over JavaVirtualMachines and
/usr/libexec/java_home? There is a currently active JDK, from
JavaVirtualMachines.
I move the jdk-13 to my ~/Documents folder. Then…
java -version
openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7)
OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode,
sharing)
is the current in the JavaVirtualMachines directory.
Now I run jpackage like so…
~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version
jpackage version 13-internal
Which is a little disappointing for the purposes of this demo. It was supposed
to totally fail. I was told jpackage was only meant to work with jdk-13 but it
clearly at least somewhat works with jdk-12.
Still, this is not actually correct. I believe it is using the
JavaVirtualMachines jdk-12 for any java and not the jdk-13 it is included with.
You could probably get around that by setting JAVA_HOME and maybe setting the
PATH environment variable. This is what I just did on an Ubunutu image on
VirtualBox. However, it was not the Mac way from the very beginning. Why bother
to do this when you can simply use the provided JavaVirtualMachines and
/usr/libexec/java_home on OS X. As was pointed out in the prior posts. What
advantage does another directory give you? What is being interfered with by
using the JavaVirtualMachines directory? With /usr/libexec/java_home you can
get any other java to use any of the other included jdk’s and an application
can be made to use an embedded jre/jdk of whatever version.
