Temurin-build: Les builds pour MacOS ne sont pas reconnus par les outils Java

Voici la structure de fichiers attendue par 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

Cela peut être un pour le projet d'installation, mais voyons voir.

Lors de la création des JDK JVMCI disponibles sur http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html , nous conservons le préfixe Contents/Home pour la version macOS précisément pour le raisons ont commencé dans ce numéro.

> 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 Puisque vous construisez avec succès via les nouveaux scripts de construction, pouvez-vous jeter un œil à celui-ci?

@karianna Je ne pense vraiment pas que nos builds devraient produire les binaires dans cette structure! Nous devrions probablement faire cette partie du programme d'installation pour MacOS afin qu'ils aient la bonne structure, mais nos archives tar devraient rester les mêmes IMO.

Ouais, je ne suis pas sûr si l'installateur ou la construction produit la bonne structure cependant ...

la construction ne le fait pas (et je ne pense pas que cela devrait), le programme d'installation peut être configuré pour produire cette structure

Je ne sais pas si je signale quelque chose que tout le monde sait déjà, mais de toute façon ...

Quand je construis le JDK sur mon Mac, make images construit l'arborescence de répertoires requise pour MacOS sous build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk/ , en plus de "l'arborescence linux standard" sous 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

Il semble donc qu'une archive d'installation MacOS "correcte" pourrait être créée en sélectionnant simplement un autre répertoire source lors de sa création.

Voir également https://github.com/AdoptOpenJDK/homebrew-openjdk/issues/9

Cela m'a du tout confondu.

Je m'attendais soit

• Un programme d'installation Mac complet (y compris le fichier .plist)
  OU ALORS
• un simple tar / archive, que je placerais manuellement sous ~ / java / ... etc

Actuellement, si je prends un fichier dans ce format et que je double-clique sur le gz, il décompresse comme d'habitude. Si j'essaie ensuite d'ouvrir (dans l'explorateur de fichiers), je reçois simplement une invite de terminal. Rien de plus. Rien ne se lance.

Je peux bien sûr configurer le jdk avec 'jenv' ou l'utiliser avec IntelliJ - juste en passant devant Contents / Home, mais cela semble "étrange". ce n'est ni une chose ni une autre. Juste ma pensée ...

@ planetf1 La «méthode macOS» (attendue par des outils comme /usr/libexec/java_home ) est de placer vos JDK sous /Library/Java/JavaVirtualMachines et ils ont besoin d'une structure de répertoire spécifique avec un fichier .plist. La structure des répertoires commence par Content/ , ce qui n'est pas affiché par Finder, ce qui est probablement ce qui vous déroute, mais c'est là. Si vous cliquez avec le bouton droit et ouvrez le contenu du package, vous le verrez également dans le Finder.

Je vois que https://adoptopenjdk.net/installation.html n'explique pas vraiment que c'est une bonne idée de déplacer le JDK sous /Library/Java/JavaVirtualMachines . Ce serait bien, car vous n'avez pas non plus besoin de modifier votre $PATH et /usr/bin/java le trouvera.

Je pense que le dernier point est saillant ... L'installation d'oracle jdk se copiera dans ce répertoire. L'utilisateur n'a rien d'autre à faire pour «simplement utiliser» le JDK.

Sur les documents ... beaucoup ne lisent pas les documents, donc au minimum un avertissement ou une information dans l'installation réelle ou autrement très évidente aiderait si cela n'est pas automatisé.

De plus, en tant qu'ingénieur logiciel créant des applications Java, je dois travailler avec plusieurs jdks, donc j'aime le fait qu'il ne soit pas installé par défaut. J'utilise 'jenv' pour gérer sur macOS. C'était juste le packaging actuel qui semble pris entre ces deux approches. Il convient également de noter que certaines applications commerciales échoueront avec les nouvelles versions de JDK, donc la mise à jour de la version `` par défaut '' même en tant qu'utilisateur novice peut être problématique.

Je suis également ingénieur logiciel et j'ai plusieurs JDK installés. Je n'utilise pas jenv , mais définissez ma version JDK majeure par défaut dans le profil de mon shell comme ceci:

Par défaut sur Java 8:

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

Par défaut sur JDK 11:

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

Si vous avez défini ce paramètre sur 1.8 par exemple, rien ne s'interrompra en ajoutant l'installation de JDK 11, car votre version majeure par défaut de JDK ne changera pas.

Je pense que le problème d'origine est résolu avec les versions actuelles d'AdoptOpenJDK 8u192 et 11.0.1 pour macOS.