MacOS Binary Changes

As a result of a recent change in our build-scripts, the directory layout of our macOS tarballs has changed. Many developers had requested that we ship our binaries in the native macOS binary layout rather than our traditional JDK layout.

Why the change?

There are several good reasons to change the directory layout to match most of the other Java implementations. The main reason that we have chosen to do so is to allow our Homebrew recipes to be merged into core making it much easier for developers to easily download our binaries!

What does this mean for me?

Essentially the directory tree has changed, previously when you extracted our macOS tarballs the bin and lib directories were located in the root directory. Native macOS Java binaries alongside most other Java implementations don’t come bundled this way. Instead a Contents directory containing Home and MacOS directories along with an Info.plist file is shipped.

What do I need to change?

The actual OpenJDK binary is identical so your Java applications will run in the exact same way but you may need to modify your PATH to accommodate these changes. If you are looking for the bin and lib directories, they are now located inside Contents/Home/bin and Contents/Home/lib.

└── Contents
    ├── Home
    │   ├── bin
    │   ├── conf
    │   ├── demo
    │   ├── include
    │   ├── jmods
    │   ├── legal
    │   ├── lib
    │   ├── man
    │   └── release
    ├── Info.plist
    └── MacOS
        └── libjli.dylib -> ../Home/lib/jli/libjli.dylib



9 thoughts on “MacOS Binary Changes”

  1. Hi, I am installing adoptopenjdk for ubuntu following the instructions on .

    Yesterday I installed adoptopenjdk 11 on a Ubuntu server and it worked fine as per the instructions. 18th July AEST
    Today I tried on a new Ubuntu server the same process and I am having the following issue reproducible across multiple agents:

    sudo apt-get update
    Hit:1 xenial InRelease
    Hit:2 stable InRelease
    Get:3 xenial InRelease [66.2 kB]
    Hit:4 xenial InRelease
    Get:5 xenial-updates InRelease [109 kB]
    Get:6 xenial-security InRelease [109 kB]
    Get:7 xenial-backports InRelease [107 kB]
    Ign:8 xenial InRelease
    Get:9 xenial-updates/main amd64 Packages [989 kB]
    Get:10 xenial-updates/universe amd64 Packages [756 kB]
    Get:11 xenial Release [4,436 B]
    Get:12 xenial Release.gpg [821 B]
    Get:13 xenial-security/main amd64 Packages [700 kB]
    Get:14 xenial/main amd64 Packages [3,367 B]
    Get:15 xenial-security/universe amd64 Packages [449 kB]
    Fetched 3,295 kB in 3s (913 kB/s)
    Reading package lists… Error!
    E: Encountered a section with no Package: header
    E: Problem with MergeList /var/lib/apt/lists/adoptopenjdk.jfrog.io_adoptopenjdk_deb_dists_xenial_main_binary-amd64_Packages
    E: The package lists or status file could not be parsed or opened.

  2. I have recently started moving from OracleJDK to AdoptOpenJDK.

    My first pass was using a pkg built by another Mac contributor and based on the tgz, it installed in to /Library/Java/JavaVirtualMachines/jdk8u212-b03/

    This was the sort of path I expected in that the folder name reflected the version number of the JDK.

    I have now run the official signed pkg and it has installed in to /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/

    I have no problem with the folder structure changing as per this article but I was wondering about the fact that the folder name no longer reflects the version. It would make it impossible – which might be a good thing to have more than one version installed.

    Note: On a Mac the command /usr/libexec/java_home -V will list all installed versions and their file paths unlike the more basic java -version command which only lists the default version.

      1. I think it’s actually really nice to have one folder per major version. This is also the scheme I use for my AdoptOpenJDK packages in MacPorts and this also makes sure you don’t need to change anything in my IDE when updating.

        Requiring multiple updates per major version to be installed sounds like a very niche use case (for debugging behavior changes between updates?), for which you could use the tarballs.

  3. Thanks for great info, but one note if I am note mistaken the following 2 directories list are identical

    they are now located inside Contents/Home/bin and Contents/Home/lib.

  4. I see the OpenJDK 11+28 release now uses this format, but the current OpenJDK 8 and 10 builds don’t use it yet. Will they upon the next release or will the current release be replaced?

Leave a Reply