Temurin-build: DLL manquantes signifie que les utilisateurs sont obligés de télécharger le redistribuable Microsoft Visual C ++

@johanvos - Est-ce quelque chose que vous attendez de notre distribution ou est-ce que cela fait partie du package JavaFX?

Il fait partie de la distribution OpenJDK, donc pour des raisons de cohérence, je pense qu'il devrait également faire partie de la distribution AdoptOpenJDK?

Super merci! @ ali-ince / @johnoliver une question à examiner

L'inclusion de dll dans le package augmenterait la taille de la distribution OpenJDK, ce qui devrait être une considération. Microsoft ne recommande pas la liaison statique ou n'inclut pas la DLL dans votre propre répertoire car la mise à jour du système d'exploitation / de sécurité peut ne pas s'appliquer à ces runtime

En regardant: https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls

Il semble que ce soient des bibliothèques au niveau du système d'exploitation, mais elles ont changé le nom d'une manière ou d'une autre. La suggestion de la communauté MS est que nous devrions utiliser mincore.lib qui est un shim pour toute la surface de l'API, mais le binaire ne fonctionnerait qu'avec Windows 8+.

Sinon, nous pouvons probablement distribuer le programme d'installation redistribuable Visual C ++ complet dans notre package d'installation.

Quelle serait une bonne option?

@sunnythepooh

Sinon, nous pouvons probablement distribuer le programme d'installation redistribuable Visual C ++ complet dans notre package d'installation.

Beurk !!!

AdoptOpenJDK devrait remplacer la version jdk.java.net.

Si vous faites sauter les utilisateurs finaux à travers des cerceaux, cela serait très dommageable pour la proposition de valeur des applications jlink'd sans dépendance.

À mon humble avis, bien que je peux voir la raison pour laquelle vous envisager d' inclure vous ne devez inclure le Redist dans AdoptOpenJDK du VC, si un .dll l' exige et parce que la seule chose qui exige est propre .dll de JavaFX, alors la raison d'inclure sembler étrange .

Il est plus judicieux pour le package JavaFX de l'inclure.

Ou inclus dans un paquet supplémentaire AdoptOpenJavaFX :-)

Il est plus judicieux pour le package JavaFX de l'inclure.

Je peux voir que vous avez peut-être tout à fait raison de dire que les .dll dans un monde idéal devraient être dans un package JavaFX.

En attendant, jusqu'à ce que vous puissiez commencer à fournir votre propre package AdoptOpenJavaFX ou convaincre Gluon d'inclure les .dlls dans leur package, AdoptOpenJDK est inutilisable pour les applications JavaFX.

Je suis sûr qu'il existe toutes sortes de meilleures approches à long terme, mais en attendant, c'est un état de limbes inacceptable pour AdoptOpenJDK.

Je pense que le principal problème ici peut être qu'AdoptOpenJDK construit le JDK avec une version différente de Visual Studio (je vais vérifier mais c'est probablement VS2013) que ce avec quoi JavaFX est construit (étant donné les noms de DLL manquants, c'est probablement VS2017).

Je vais d'abord essayer de vérifier la version de VS et de mettre à jour ici.

J'ai remarqué qu'AdoptOpenJDK 12 (hotspot) a maintenant les DLL nécessaires, donc tout fonctionne parfaitement pour les applications JavaFX.

Merci!!!

J'ai remarqué qu'AdoptOpenJDK 12 (hotspot) a maintenant les DLL nécessaires, donc tout fonctionne parfaitement pour les applications JavaFX.

Merci!!!

Bon à entendre - Pour Java 11 et 8, je soupçonne que ce problème sera résolu dans les nightlies maintenant. @ ali-ince Construisons-nous avec VS 2017 pour toutes les versions maintenant?

Pas encore @karianna , c'est toujours en cours. Je mettrai à jour ce fil lorsque nous passerons à vs2017.

Une mise à jour rapide à ce sujet;

1. Les versions 64 bits de JDK11u sont désormais basculées vers VS2017.
2. Les versions 32 bits de JDK11u sont sur VS2013. Un correctif qui permettra à JDK11u 32 bits de se compiler avec VS2017 sera lancé avec la mise à jour 11.0.4 et nous passerons à VS2017 parallèlement à cela.
3. Les versions 32 bits et 64 bits de JDK8u sont désormais basculées vers VS2013 (auparavant, elles étaient mixées sur VS2010 / VS2013). Nous travaillons pour que ceux-ci s'appuient également sur VS2017, mais cela semble prendre un peu plus de temps pour obtenir un correctif à soumettre en amont.

Salut!
Nous avons des problèmes dans notre environnement client avec les bibliothèques d'exécution C manquantes.
Quel est le statut de ce problème?

La solution de contournement serait d'installer le runtime C sur TOUS des milliers de systèmes clients qui ne l'ont pas installé avec le système d'exploitation.
Nous ne pouvons pas forcer notre client à faire cela ou à passer par exemple de Windows Server 2012 R2 à des versions plus récentes tant que Microsoft lui-même prend en charge ces versions.

//ÉDITER:
Existe-t-il d'autres solutions de contournement en attendant?