Temurin-build: Сборки для MacOS не распознаются инструментами Java

Это файловая структура, которую ожидает macOS:

➜  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

Это может быть проект установщика, но давайте посмотрим.

При сборке JDK JVMCI, доступных по адресу http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html , мы сохраняем префикс Contents/Home для сборки macOS именно для причины начались в этом вопросе.

> 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

@johnoliver Поскольку вы успешно строите с помощью новых сценариев сборки, можете ли вы взглянуть на этот?

@karianna Я действительно не считаю, что наши сборки должны создавать бинарные файлы в этой структуре! Вероятно, нам следует сделать эту часть установщика для MacOS, чтобы они имели правильную структуру, но наши tarballs должны оставаться такими же, как IMO.

Да, я не уверен, что установщик или сборка создает правильную структуру ...

сборка не (и я не думаю, что должна), установщик может быть настроен для создания этой структуры, хотя

Не знаю, укажу ли я на то, что все уже знают, но в любом случае ...

Когда я создаю JDK на своем Mac, make images строит необходимое дерево каталогов для MacOS в build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk/ в дополнение к "стандартному дереву Linux" в 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

Таким образом, кажется, что «правильный» установочный архив MacOS можно создать, просто выбрав другой исходный каталог при его создании.

Также см. Https://github.com/AdoptOpenJDK/homebrew-openjdk/issues/9.

Меня это вообще смутило.

Я либо ожидал

• Полный установщик Mac (включая файл .plist)
  ИЛИ ЖЕ
• простой tar / архив, который я бы вручную поместил в ~ / java / ... и т. д.

В настоящее время, если я возьму файл в этом формате и дважды щелкну по gz, он распакуется как обычно. Если я затем попытаюсь открыть (в проводнике файлов), я просто получу приглашение терминала. Ничего больше. Ничего не запускается.

Я, конечно, могу настроить jdk с помощью jenv или использовать с IntelliJ - просто прыгая мимо Contents / Home, но это кажется «странным». это ни то, ни другое. Просто моя мысль ....

@ planetf1 "способ macOS" (ожидаемый такими инструментами, как /usr/libexec/java_home ) заключается в том, чтобы поместить ваши JDK в /Library/Java/JavaVirtualMachines и им нужна определенная структура каталогов с файлом .plist. Структура каталогов начинается с Content/ , который не отображается Finder, что, вероятно, вас смущает, но оно есть. Если вы щелкните правой кнопкой мыши и откройте содержимое пакета, вы также увидите его в Finder.

Я вижу, что https://adoptopenjdk.net/installation.html на самом деле не объясняет, что переместить JDK в /Library/Java/JavaVirtualMachines - хорошая идея. Это было бы хорошо, поскольку тогда вам также не нужно изменять свой $PATH и /usr/bin/java просто найдет его.

Я думаю, что последний пункт важен ... Установка oracle jdk скопирует себя в этот каталог. Пользователю не нужно ничего делать, чтобы «просто использовать» JDK.

В документах ... многие не читают документы, поэтому, как минимум, предупреждение или информация в фактической установке или иным образом очень очевидны, если это не автоматизировано.

Кроме того, как программисту, создающему java-приложения, мне нужно работать с несколькими jdks, поэтому мне нравится, что он не установлен по умолчанию. Я использую jenv для управления в macOS. Просто нынешняя упаковка, кажется, застряла между этими двумя подходами. Также следует отметить, что некоторые коммерческие приложения не работают с новыми версиями JDK, поэтому обновление версии по умолчанию даже для начинающего пользователя может быть проблематичным.

Я также инженер-программист, и у меня установлено несколько JDK. Я не использую jenv , но устанавливаю основную версию JDK по умолчанию в профиле оболочки следующим образом:

По умолчанию для Java 8:

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

По умолчанию JDK 11:

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

Например, если для этого параметра установлено значение 1.8 , добавление установки JDK 11 не помешает, потому что основная версия JDK по умолчанию не изменится.

Я считаю, что исходная проблема исправлена ​​в текущих выпусках AdoptOpenJDK 8u192 и 11.0.1 для macOS.