> 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.
