Temurin-build: Builds for MacOS are not recognized by Java Tools

[mbidewell]

If I follow the instructions for installing AdoptOpenJDK builds on MacOS, I get a functioning command line, however /usr/libexec/java_home does not recognize the install (Even if placed into /Library/Java/JavaVirtualMachines) due to the directory structure and lack of an Info.plist file. The Java 10 build from http://jdk.java.net/10/ contains the correct information, however builds from adoptopenjdk do not. IDEs such as Eclipse and Intelij also do not recognize the AdoptOpenJDK binaries.

This makes adoptopenjdk unsuable on MacOS for all practical purposes.

[gdams]

This is the file structure that macOS expects:

➜  jdk1.8.0_121.jdk tree -v -L 3 --charset utf-8
.
└── Contents
    ├── Home
    │   ├── ASSEMBLY_EXCEPTION
    │   ├── COPYRIGHT
    │   ├── LICENSE
    │   ├── README.html
    │   ├── THIRDPARTYLICENSEREADME-JAVAFX.txt
    │   ├── THIRDPARTYLICENSEREADME.txt
    │   ├── THIRD_PARTY_README
    │   ├── bin
    │   ├── db
    │   ├── demo
    │   ├── include
    │   ├── javafx-src.zip
    │   ├── jre
    │   ├── lib
    │   ├── man
    │   ├── release
    │   ├── sample
    │   └── src.zip
    ├── Info.plist
    └── MacOS
        └── libjli.dylib -> ../Home/jre/lib/jli/libjli.dylib

11 directories, 12 files

[karianna]

This may be one for the installer project, but lets see.

[dougxc]

When building the JVMCI JDKs available at http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html, we preserve the Contents/Home prefix for the macOS build for precisely the reasons started in this issue.

> tree -L 3 /Library/Java/JavaVirtualMachines/labsjdk1.8.0_172-jvmci-0.44
/Library/Java/JavaVirtualMachines/labsjdk1.8.0_172-jvmci-0.44
└── Contents
    ├── Home
    │   ├── COPYRIGHT
    │   ├── LICENSE
    │   ├── README.html
    │   ├── THIRDPARTYLICENSEREADME-JAVAFX.txt
    │   ├── THIRDPARTYLICENSEREADME.txt
    │   ├── bin
    │   ├── db
    │   ├── include
    │   ├── javafx-src.zip
    │   ├── jre
    │   ├── lib
    │   ├── man
    │   ├── release
    │   └── src.zip
    ├── Info.plist
    └── MacOS
        └── libjli.dylib -> ../Home/jre/lib/jli/libjli.dylib

9 directories, 10 files

[karianna]

@johnoliver Since you're successfully building via the new build scripts - are you able to take a look at this one?

[gdams]

@karianna I really don't feel that our builds should be churning out the binaries in this stucture! We should probably make this part of the installer for MacOS so that they do have the correct structure but our tarballs should remain the same IMO.

[karianna]

Yeah I'm not sure if the installer or the build produces the right structure though...

[gdams]

the build doesn't (and I don't think it should) the installer can be configured to produce this structure though

[lenborje]

I don't know if I point out something everybody already knows, but anyway...

When I build the JDK on my Mac, make images builds the requisite MacOS-friendly directory tree under build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk/, in addition to the "standard linux tree" under build/macosx-x86_64-normal-server-release/images/jdk/:

$ tree -L 3 build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk
build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk
└── Contents
    ├── Home
    │   ├── bin
    │   ├── conf
    │   ├── demo
    │   ├── include
    │   ├── jmods
    │   ├── legal
    │   ├── lib
    │   ├── man
    │   └── release
    ├── Info.plist
    └── MacOS
        └── libjli.dylib -> ../Home/lib/jli/libjli.dylib
$ tree -L 1 build/macosx-x86_64-normal-server-release/images/jdk
build/macosx-x86_64-normal-server-release/images/jdk
├── bin
├── conf
├── demo
├── include
├── jmods
├── legal
├── lib
├── man
└── release

So it seems to that a "correct" MacOS installation archive could be created by simply selecting another source directory when creating it.

[karianna]

Also, see https://github.com/AdoptOpenJDK/homebrew-openjdk/issues/9

[planetf1]

I got confused by this at all.

I was either expecting

• A full mac installer (including the .plist file)
  OR
• a simple tar/archive, that I would manually place under ~/java/ ... etc

Currently if I take a file in this format and double click on the gz it unpacks as usual. If I then try and open (in the file explorer) I just get a terminal prompt. Nothing more. Nothing launches.

I can of course configure the jdk with 'jenv' or to use with IntelliJ - just jumping past Contents/Home, but it feels 'odd'. it's neither one thing nor the other. Just my thought....

[breun]

@planetf1 The 'macOS way' (expected by tools like /usr/libexec/java_home) is to put your JDK's under /Library/Java/JavaVirtualMachines and they need a specific directory structure with a .plist file. The directory structure starts with Content/, which is not shown by Finder, which is probably what's confusing you, but it is there. If you right click and open package contents you'll see it in Finder as well.

[breun]

I see https://adoptopenjdk.net/installation.html doesn't really explain it's a good idea to move the JDK under /Library/Java/JavaVirtualMachines. That would be good, since then you also don't need to modify your $PATH and /usr/bin/java will just find it.

[planetf1]

I think the last point is salient ... The oracle jdk install will copy itself into that directory. The user needs to do nothing else to 'just use' the JDK.

On docs... many don't read the docs, so at a minimum a warning or info in the actual install or otherwise very obvious would help if this isn't automated.

Also as a software engineer building java apps I need to work with multiple jdks, so I like the fact it isn't installed by default. I use 'jenv' to manage on macOS. It was just the current packaging seems caught between these two approaches. Of note also is that some commercial apps will fail with new versions of JDKs, so updating the 'default' version even as a novice user can be problematic

[breun]

I'm also a software engineer and I have multiple JDK's installed. I don't use jenv, but set my default major JDK version in my shell's profile like this:

Default to Java 8:

export JAVA_HOME=`/usr/libexec/java_home -v 1.8`

Default to JDK 11:

export JAVA_HOME=`/usr/libexec/java_home -v 11`

If you have this set to 1.8 for instance, nothing will break adding installing JDK 11, because your default JDK major version will not change.

[breun]

I believe the original issue is fixed with the current AdoptOpenJDK 8u192 and 11.0.1 releases for macOS.