Temurin-build: JavaFX est manquant dans les distributions OpenJDK 8

Créé le 27 sept. 2018  ·  116Commentaires  ·  Source: adoptium/temurin-build

Bonjour,

actuellement, les bibliothèques JavaFX sont absentes des distributions Windows OpenJDK 8. Est-il prévu d'inclure JavaFX dans les distributions AdoptOpenJDK ?

Merci d'avance pour votre aide!

enhancement wontfix

Commentaire le plus utile

Je pense que les développeurs qui ont besoin de JavaFX groupé (OpenJFX) peuvent utiliser les distributions ci-dessous.

ZuluFX et Liberica sont pris en charge par JDK 8/11, Corretto est désormais uniquement JDK 8 et en avant-première.

Tous les 116 commentaires

@SzentnerTsIT Oui, nous avons déjà quelques problèmes ouverts à ce sujet. Ça va prendre quelques semaines au mieux j'en ai peur. Nous allons commencer par Java 11 et revenir en arrière

Est-ce que ce problème avec AdoptOpenJdk 1.8u192b12 sous Linux (pas Windows),
ne devrait-il pas fonctionner ou est-ce que j'ai raté quelque chose ?
TIA pour votre réponse

Voir également #245 - il s'agit peut-être aussi d'un problème d'installation - repoening.

Je n'utilise pas le programme d'installation, je décompresse l'archive téléchargée et utilise "update-alternatives --install" pour installer le jdk (notez que ce n'est pas exactement le problème d'origine, il s'agit d'un problème Linux).
J'ai vu que le jfxrt.jar est manquant dans la distribution AdoptOpenJDK lors de la comparaison du contenu du répertoire jre/lib/ext d'AdoptOpenJDK 8u192 (1ère fenêtre) et d'oracle jdk 1.8u192 (2ème fenêtre) (voir la capture d'écran ci-jointe) c'est peut-être le problème?
Merci pour ta réponse en tout cas
image

Quelles versions de Windows incluent JavaFX ?

@alexhass , Windows oracle jdk 1.8 le fait, je n'ai pas de système Windows pour le moment pour faire une capture d'écran, mais en regardant le site Web de la doc, vous voyez que l'API est incluse dans 1.8. https://docs.oracle.com/javase/8/javafx/api/toc.htm
JavaFX est passé à openJFX à partir de 1.8 (c'est-à-dire 9, 10 et 11)

Il y a 2 semaines, j'ai testé PDFsam sur Windows avec 8.x et il s'est plaint de ne pas pouvoir détecter Java. Je suppose simplement qu'il n'est pas intégré. Peut-être un bug dans pdfsam.

Je télécharge jdk8u192-b12-jre et vérifie à nouveau le chemin \lib\ext\ et il n'y a PAS de jfxrt.jar

Vous devez regarder le répertoire jre sous jdk et non jre en dehors de l'arborescence des répertoires jdk.
Ici sur une machine windows avec jdk 191 (capture d'écran prise hier, je n'ai pas installé 192 car ce n'est pas ma machine) :
jdk-jfxrt
J'ai remarqué le problème car j'ai du code qui compile (sous linux) avec oracle jdk et qui ne compile pas avec Adoptopenjdk (sous linux) car il ne trouve pas les packages javafx, le projet open source corda. Je n'ai pas essayé Adoptopenjdk sous Windows.
Ce projet utilise en fait jdk 1.8, et je ne peux pas passer facilement à jdk11, il s'agit de 5,4 millions de lignes de code et il y a quelques ajustements spécifiques, il y a une quantité importante de travail.
Et je ne l'ai pas dit mais je suis très reconnaissant à toutes les personnes qui maintiennent la distribution Adoptopenjdk et les remercie pour leur travail, c'est une initiative très importante

Vous faites référence à Oracle Java. Mais je parle du JRE d'AdoptOpenJDK.

Il manque JavaFX aux packages AdoptOpenJDK. Cela cause beaucoup de problèmes. Par exemple, PDFsam ne peut pas être utilisé sous Windows.

Oui, j'ai vérifié Oracle jdk .
Il semble que les bibliothèques javafx manquent à la fois dans les versions Linux et Windows AdoptOpenJDK.

Existe-t-il un ETA sur le moment où JavaFX peut être inclus dans les versions 8.x ?

J'espère que cela sera résolu avant qu'Oracle Java 8 n'atteigne la fin de vie en deux ? plus de versions (u211).

Un ETA avec Oracle Java 8 EOL à venir ?

Merci
Michael

Je pense que les développeurs qui ont besoin de JavaFX groupé (OpenJFX) peuvent utiliser les distributions ci-dessous.

ZuluFX et Liberica sont pris en charge par JDK 8/11, Corretto est désormais uniquement JDK 8 et en avant-première.

Nous cherchons à conseiller à nos clients d'utiliser adoptopenjdk avec notre produit. La plupart de nos produits n'utilisent pas javafx.

En raison du coût de la validation, nous prendrons en charge une seule distribution Java. Nous aimerions utiliser adoptopenjdk.

Y a-t-il un ETA sur openJFX dans la distribution Windows. Nous allons bien avec les distributions linux java 1.8 d'openjdk pour le moment. Le premier de la falaise est Windows Java 1.8.

Nous espérons avoir quelque chose en place d'ici la fin du premier trimestre au plus tard

@karianna si c'est le cas, ce serait la dernière version EOL de Java 8, n'est-ce pas ? J'ai besoin d'une version 32 bits.
IBM l'aura également (J9 et non OpenJ9) longtemps après la fin de vie entrante si vous recherchez "Ship Java 8 APAR FOR WAS"

@karianna si c'est le cas, ce serait la dernière version EOL de Java 8, n'est-ce pas ? J'ai besoin d'une version 32 bits.
IBM l'aura également (J9 et non OpenJ9) longtemps après la fin de vie entrante si vous recherchez "Ship Java 8 APAR FOR WAS"

Nous l'ajouterons probablement à AdoptOpenJDK en tant qu'option dans les programmes d'installation. Pour win-32, cela peut être délicat. @johanvos et @ali-ince devront commenter la faisabilité de cela.

Il y a plus que juste jfxrt.jar . Si vous recherchez dans la distribution Oracle JDK des fichiers contenant fx , vous trouverez environ une douzaine de fichiers qui semblent pertinents. Amazon Corretto a jfxrt.jar mais il manque jfxwebkit.dll et quelques autres, en plus son fichier jfxrt.jar est beaucoup plus petit. La distribution Amazon n'est pas complète non plus, la compilation peut fonctionner mais plante à l'exécution si javafx webkit est utilisé. J'espère qu'adoptjdk a inclus la prise en charge de toutes les fonctionnalités javafx dans JDK8, j'ai vraiment besoin de webkit pour fonctionner !

Je suis heureux de vos efforts pour fournir un LTS JDK/RE 8 gratuit. Hélas, un remplacement direct pour Oracle JDK/JRE 8 sans prise en charge complète de JavaFX n'est pas un véritable remplacement direct.

Nous avons besoin de la prise en charge de JavaFX pour les tests Selenium avec JBrowserDriver (https://github.com/MachinePublishers/jBrowserDriver) pour les tests d'interface utilisateur sans tête sur un serveur de build Jenkins. Une très bonne solution Java uniquement. L'autre navigateur prenant en charge le mode sans tête est Chrome. Mais c'est un PITA de courir. Nous avons finalement abandonné parce que nous avons mieux à faire.

Étant donné que JBrowserDriver utilise le composant HtmlKit de JavaFX, il se bloque sur les distributions OpenJDK 8 actuelles. Il existe certainement de nombreuses autres applications Open Source et propriétaires qui ne fonctionneront pas sans JavaFX.

Si de l'aide est nécessaire, par exemple pour tester une version préliminaire et des commentaires, je serais heureux de la fournir. Nous utilisons AdoptOpenJDK avec Open J9 VM pour la compilation et comme environnement d'exécution pour WebSphere Liberty sur nos machines de développeurs et pour la compilation et comme environnement de test (maven). La seule exception pour le moment sont nos tests Selenium.

L'environnement d'exécution OpenJDK (AdoptOpenJDK) (build 1.8.0_202-b08) n'a pas JavaFX.
Comment inclure ?

L'environnement d'exécution OpenJDK (AdoptOpenJDK) (build 1.8.0_202-b08) n'a pas JavaFX.
Comment inclure ?

À court terme, je me dirigerais vers OpenJFX et demanderais à leur communauté - il faudra un peu de temps avant de régler l'histoire ici.

Bonjour,

y a-t-il des informations quand le javafx sera disponible dans AdoptOpenJDK 8. Nous en avons vraiment besoin.

Une solution de contournement possible :
Je travaille sur le système Ubuntu 18.04 et j'utilise la version AdoptOpenJDK 8u202-b08.
Pour faire fonctionner Javafx, j'ai copié tous les fichiers nécessaires de la version Oracle JDK 1.8.0_201 vers AdoptOpenJDK. Après les fichiers que vous devez copier :

javafx-src.zip
bin/javafxpackager
jre/lib/javafx.properties
jre/lib/jfxswt.jar
jre/lib/ext/jfxrt.jar
jre/lib/javafx.properties
jre/lib/amd64/libjavafx_font_freetype.so
jre/lib/amd64/libjfxwebkit.so
jre/lib/amd64/libjfxmedia.so
jre/lib/amd64/libjavafx_iio.so
jre/lib/amd64/libjavafx_font_t2k.so
jre/lib/amd64/libfxplugins.so
jre/lib/amd64/libjavafx_font_pango.so
jre/lib/amd64/libjavafx_font.so
jre/lib/amd64/libglass.fo
jre/lib/amd64/libprism_common.so
jre/lib/amd64/libprism_es2.so
jre/lib/amd64/libprism_sw.so
lib/ant-javafx.jar
lib/javafx-mx.jar

Je ne sais pas si vous avez besoin exactement des mêmes fichiers sous Windows, mais j'espère que cela vous aidera pour l'instant à faire fonctionner votre application avec AdoptOpenJDK.

@karianna des nouvelles ?

@karianna des nouvelles ?

C'est assez haut dans la liste, mais nous avons d'abord d'autres priorités de gravure (installateurs et JDK12)

@karianna de quoi avez-vous besoin pour obtenir javafx dans AdoptOpenJDK ?

Je pense que nous avons juste besoin d'ajouter les bibliothèques correctes au bundle JRE / JDK existant, puis de les rendre disponibles en tant que téléchargement séparé et via des programmes d'installation également. Donc probablement des scripts Jenkins Groovy / Bash, des mises à jour du programme d'installation, puis du travail sur les API et le Web.

J'ai réussi à construire OpenJFX 1.8 sur une machine Windows 10, avec le jfxwebkit.dll, etc., également construit. Teste bien. C'était un exercice très douloureux, les guides de construction d'openjfx sur le Web sont parfois insuffisamment précis sur certaines fonctionnalités des versions exactes des packages d'outils qui fonctionnent ensemble, et quels packages sont mieux chargés à la main et non téléchargés avec cygwin. L'ordre PATH est également crucial pour sélectionner les bons compilateurs, la bonne marque, etc. Ça peut être fait.

Les distributions MacOS et Linux manquent également les bibliothèques JavaFX...

@karianna dans le cadre de ce numéro, OpenJFX sera-t-il également fourni dans les distributions MacOS et Linux ? Si tel est le cas, pouvez-vous s'il vous plaît mettre à jour le titre du problème pour refléter la portée.

Je viens de passer sous Windows à cause de Ninite. Maintenant, plusieurs programmes ne fonctionnent plus, et je vais dans le terrier du lapin pour voir comment réparer sans revenir au propriétaire d'oracle. Nous avons vraiment besoin d'un remplacement sans rendez-vous qui fonctionne simplement comme un remplacement sans rendez-vous.
Je comprends que cela représente beaucoup d'efforts de la part de plusieurs personnes, et je n'ai pas l'intention de manquer de respect ou de mépris pour le travail fourni. Je signale simplement un problème. Maintenant qu'adoptopenjdk va voir beaucoup de nouveau trafic à la suite des actions d'Oracle, nous ne voulons pas que des personnes moins techniques pensent qu'OpenJDK est indésirable parce que les choses ne fonctionneront pas.

@Sakata-MC La communauté travaillera sur OpenFX et en fera un citoyen de première classe. Si vous recherchez un soutien supplémentaire dans ces efforts, consultez les options sur adoptopenjdk.net/support.html

@Sakata-MC @kariana Amazon Correto contient des bibliothèques JFX pour tous les systèmes d'exploitation. Mais n'avez pas de JVM OpenJ9.

J'ai également recherché un support javaFX pour iOS.

Je cherchais également un remplaçant pour Oracle JDK 8 et malheureusement, aucune des alternatives ne fait la coupe. Le support Win32 ou Mac est manquant (tous sauf AdoptOpenJDK) et/ou il n'y a pas de JavaFX avec WebKit et javafxpackager.

Je me demande vraiment ce qui peut avoir une priorité plus élevée que la parité des fonctionnalités. Le prio devrait être beaucoup augmenté. Le projet est vraiment lourd derrière...

@alexhass Les Pull Requests et le support sont les bienvenus ! - Sinon, vous pouvez consulter adoptopenjdk.net/support.html pour accélérer les fonctionnalités.

Je vais essayer cette distribution que j'ai trouvé par hasard :
https://www.azul.com/downloads/zulu/zulufx/

Je ne savais pas qu'il existe une version communautaire gratuite et sans restriction de Zulu JRE/JDK.

Les DLL Webkit sont présentes. Je pense que les autres artefacts JavaFX sont également complets :

zulu8.38.0.13-ca-fx-jdk8.0.212-win_x64\bin\javafxpackager.exe
zulu8.38.0.13-ca-fx-jdk8.0.212-win_x64\jre\bin\javafx_font.dll
zulu8.38.0.13-ca-fx-jdk8.0.212-win_x64\jre\bin\javafx_iio.dll
zulu8.38.0.13-ca-fx-jdk8.0.212-win_x64\jre\bin\jfxmedia.dll
zulu8.38.0.13-ca-fx-jdk8.0.212-win_x64\jre\binjfxwebkit.dll

Je n'ai copié que les noms de fichiers des fichiers mentionnés par d'autres commentaires. Il y en a plus. Cherchez par vous-même et essayez-le si vous avez un besoin urgent d'un remplaçant.

@jmsdo Vous pouvez également essayer Liberica JDK. https://www.bell-sw.com/

Des nouvelles si cela va être prêt dans le jalon « Mai 2019 » ?

@juliojgd May est optimiste, ce sera probablement en juin

Ce problème devient de plus en plus important depuis que la dernière image docker d'OpenJDK est passée au JDK d'AdoptOpenJDK.
Avant, il était possible d'installer JavaFX en utilisant "apt get install openjfx".

Cela ne fonctionne plus et a cassé la construction pour nous.
Probablement, beaucoup de gars cherchent les raisons pour lesquelles JavaFX n'est plus disponible dans leur image docker...

https://github.com/docker-library/openjdk/blob/282961c4ca0be09af7a556e38b8d5be0c2db0608/8/jdk/Dockerfile

Voici le commit qui a changé le comportement :
https://github.com/docker-library/openjdk/commit/3eb0351b208d739fac35345c85e3c6237c2114ec#diff -fef076ee1e5f270f2c5a93d075150919

Comme mon entreprise avait besoin d'openjfx 8 pour adopteropenjdk, je l'ai compilé. Vous pouvez le construire vous-même https://benjamin-brummer.de/2019/06/03/build-openjfx-8-for-adoptopenjdk/ ou faites-moi confiance et prenez la dernière version d'ici https://benjamin-brummer.de /téléchargements/. Il suffit de l'extraire dans votre jdk.

@benbrummer Merci pour la compilation, mais il manque le libjfxwebkit dans le vôtre :
Caused by: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program Files\AdoptOpenJDK\jdk-8.0.212.03-hotspot\jre\bin\jfxwebkit.dll

@Siedlerchr j'ai téléchargé une version avec WebKit et Media

@benbrummer peut-être créer une pull request ?

Vous ne savez pas où tirer vers https://github.com/AdoptOpenJDK/openjdk-jfx est vide.

Hypothèse

  1. PR pour changer git-hg pour obtenir les sources sur Github.
  2. PR pour changer le code sur Github pour qu'il soit constructible avec AdoptOpenJDK comme cible
  3. PR pour la construction contre d'autres plates-formes (au mieux, pas besoin de cela)
  4. Intégration dans le système de construction ?

Le deuxième PR serait facile, mais je ne construis que OpenJFX pour Windows et uniquement OpenJFX 8

Vous ne savez pas où tirer vers https://github.com/AdoptOpenJDK/openjdk-jfx est vide.

Hypothèse

  1. PR pour changer git-hg pour obtenir les sources sur Github.

Nous n'aurons peut-être même pas besoin de le faire en supposant que nous n'avons pas besoin de conserver des correctifs sur ce qui se trouve dans https://github.com/javafxports/openjdk-jfx - @johanvos - si nous construisons OpenJFX chez Adopt, devons-nous définir un fournisseur chaîne ou quelque chose comme ça?

  1. PR pour changer le code sur Github pour qu'il soit constructible avec AdoptOpenJDK comme cible

Je pense qu'il s'agirait simplement de configurer un pipeline de construction Jenkins pour créer OpenJFX (tous les soirs) et publier des versions

  1. PR pour la construction contre d'autres plates-formes (au mieux, pas besoin de cela)

Tout fait partie du pipeline ci-dessus. Je pense que l'une des choses qui nous a retenus était un travail d'infrastructure pour installer les dépendances OpenJFX

https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+OpenJFX

  1. Intégration dans le système de construction ?

Le deuxième PR serait facile, mais je ne construis que OpenJFX pour Windows et uniquement OpenJFX 8

https://github.com/javafxports/openjdk-jfx n'est pas suffisant
Nous avons besoin d'un miroir de
http://hg.openjdk.java.net/openjfx/8u/rt/
http://hg.openjdk.java.net/openjfx/9/rt/ (eol)
http://hg.openjdk.java.net/openjfx/10/rt/ (eol)
http://hg.openjdk.java.net/openjfx/11/rt/
http://hg.openjdk.java.net/openjfx/12/rt/
http://hg.openjdk.java.net/openjfx/jfx-dev/rt serait 13

Les instructions de https://github.com/AdoptOpenJDK/openjdk-build/blob/master/README.md
jfx - Build OpenJFX, defaults to https://github.com/AdoptOpenJDK/openjdk-jfx
ne suffisent pas. Comme pour l'OpenJDK (jdk8u, jdk9u...). nous avons besoin de la même chose pour OpenJFX.

Nous venons de réaliser qu'il manque des dll Windows pour AdoptOpenJDK 8u212 + OpenJFX 8 Overlay. Pour exécuter une application javafx, nous devions également installer Visual C++ 2015-2019 Redistributable https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads.

Sur Lubuntu 19.04, il manque JavaFX à OpenJDK-8-JDK. Cela signifie-t-il que ce n'est plus possible avec JavaFX pour Java 8 ? Je dois passer à Java 11 si je veux faire des applications Android ?

Il est toujours possible d'utiliser JavaFX avec Java 8 @DanielMartensson .

Le problème ici est simplement que certaines distributions de Java n'incluent pas JavaFX ou l'incluent séparément.

Pour compliquer davantage les choses, Ubuntu avait un package openjfx 8 séparé, mais ils s'en sont débarrassés et n'ont plus qu'un package openjfx 11. Comme solution de contournement possible, vous pourrez peut-être ajouter des référentiels pour l'ancienne version d'Ubuntu et installer l'ancien package openjfx, mais je n'ai pas essayé cela personnellement. Plus de détails ici : https://askubuntu.com/questions/1088281/openjfx-11-after-18-10-upgrade

C'est le fichier docker qui fonctionne pour moi - y compris JavaFX :

FROM openjdk:8

RUN apt-get update && \
    apt-get install -y --no-install-recommends imagemagick openjfx git \
    && rm -rf /var/lib/apt/lists/* \
    && cp /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/jfxrt.jar /usr/local/openjdk-8/jre/lib/ext \
    && cp /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/javafx.properties /usr/local/openjdk-8/jre/lib \
    && cp /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jfxswt.jar /usr/local/openjdk-8/jre/lib \
    && cp /usr/lib/jvm/java-8-openjdk-amd64/lib/ant-javafx.jar /usr/local/openjdk-8/lib \
    && cp /usr/lib/jvm/java-8-openjdk-amd64/lib/javafx-mx.jar /usr/local/openjdk-8/lib

ENV JAVA_HOME /usr/local/openjdk-8/

@jschneider , sur quelle version d'Ubuntu avez-vous testé cela ? Comme je l'ai noté ci-dessus, je pense que le package "openjfx" a maintenant été modifié pour ne prendre en charge que Java 11 dans la nouvelle version d'Ubuntu (depuis 18.10), ce script pourrait donc ne plus fonctionner.

De plus, si cela ne vous dérange pas que je demande, pourquoi ne pas simplement définir JAVA_HOME sur /usr/lib/jvm/java-8-openjdk-amd64/ au lieu de copier tous ces fichiers dans l'autre répertoire ?

J'étends l'image de "
La dernière fois que j'ai vérifié, ça fonctionnait bien.

S'ils ont mis à jour cette image, elle peut être cassée. Je construis juste une fois par semaine.

JAVA_HOME est défini sur /usr/local/openjdk-8/ car l'emplacement du JDK a changé dans l'image de base.

Je ne dis pas que c'est la meilleure façon de le faire - juste que c'est "assez bien" pour moi.

@jschneider c'est utile, ça marche pour moi sur CentOS 7. Merci !

Ah, compris. Je ne connais pas très bien docker, donc je ne savais pas qu'il fournissait une copie du JDK de cette manière. Logique. De plus, cette image semble être basée sur Debian Stretch, donc le bogue dont je parlais ne s'applique pas. Désolé pour la confusion

J'ai résolu mon problème. J'ai dû ajouter libopenjfx-jni aussi.

1. Install OpenJDK 8

        sudo apt-get install openjdk-8-jdk

2. Install OpenJFX 8, not OpenJFX 11

Open this:

    cd /etc/apt
    sudo nano sources.list

Paste this:

     deb http://de.archive.ubuntu.com/ubuntu/ bionic universe

Run this:

    sudo apt-get update
    sudo apt install openjfx=8u161-b12-1ubuntu2 libopenjfx-java=8u161-b12-1ubuntu2 libopenjfx-jni=8u161-b12-1ubuntu2

Terminé

Pouvons-nous nous attendre à résoudre ce problème dans un avenir proche ?
Cette année?

Pouvons-nous nous attendre à résoudre ce problème dans un avenir proche ?
Cette année?

Probablement cette année oui, mais il y a un tas de priorités plus élevées que nous abordons en premier. Si vous avez besoin de quelque chose d'accéléré, il existe quelques options de support commercial (adoptopenjdk.net/support)

Nous avons un produit logiciel de bureau (nécessitant Java-FX et utilisant des hacks de réflexion qui rendent Java-9 difficile) dont j'ai récemment réalisé qu'il s'agissait probablement d'un abus de licence de la nouvelle licence d'Oracle.

J'utilise Java8+FX u222 d'Azul ( zulu8.40.0.25-ca-fx-jdk8.0.222-win_i686 ) sans problème.

Ce serait vraiment bien si AdoptOpenJDK incluait le runtime JavaFX dans leur distribution java-8.

_bien sûr, ce serait mieux si je pouvais refactoriser mon code de piratage de réflexion à partir de ma base de code et simplement passer à java-11_ (ou, d'ailleurs, à java 12, puisque cette inférence de type est vraiment sympa).

https://www.jetbrains.com/research/devecosystem-2018/java/
84% des utilisateurs utilisent Java8 - je pense qu'une API non prise en charge serait une priorité absolue.

Un an s'est écoulé... Toujours pas réglé ?

Un an s'est écoulé... Toujours pas réglé ?

Uniquement pour Linux. J'utilise OpenJFX pour le développement Android et Iphone.

Le meilleur moyen est de faire fonctionner Android avec OpenJFX 11. Ensuite, tous les utilisateurs d'Android Java passeront à Java 11.

Oui, mais comme @beatngu13 l'a déjà dit, Java 8 reste la version Java la plus utilisée : https://www.jetbrains.com/lp/devecosystem-2019/java/
Donc, le soutien pour cela est toujours nécessaire!

OpenJFX 8 n'est pas maintenu. Tant que cela ne change pas, nous n'allons pas l'inclure dans quoi que ce soit. Si vous souhaitez changer cela, dirigez-vous vers le canal OpenJFX sur AdoptOpenJDK Slack.

Entendu. Passer à Java8+FX d'Azul

Entendu. Passer à Java8+FX d'Azul

Il y a aussi Liberica, qui contient FX.
https://bell-sw.com/pages/java-8u232/

Entendu. Passer à Java8+FX d'Azul

Il y a aussi Liberica, qui contient FX.
https://bell-sw.com/pages/java-8u232/

J'ai essayé cela et cela n'a pas fonctionné pour Gluon HQ JavaFX pour le développement Android/Iphone.
AdoptOpenJDK 8 avec OpenJFX 8 fonctionne pour moi sous Linux.

J'ai mis à jour mes téléchargements pour JavaFX-Overlay.
https://benjamin-brummer.de/downloads/
De plus, j'ai ajouté un téléchargement pour les Windows-Dlls nécessaires.
Vous pouvez soit télécharger l'Overlay + les Dll et le copier sur votre AdoptOpenJDK existant, soit télécharger les fichiers AIO-Zip.

Est-ce que ça marche avec Gluon HQ JavaFX ?

Il y a aussi Liberica, qui contient FX.
https://bell-sw.com/pages/java-8u232/

@rafik777 , comment pouvez-vous dire qu'il contient des FX ? Je recherche principalement quelque chose sur lequel JavaFX est préinstallé afin de pouvoir créer mon ancienne application Java. Mais lorsque je l'ai construit avec gradle à l'aide d'une image Docker bellsoft/liberica-openjdk-debian:8 , il a signalé un tas d'erreurs comme ci-dessous :

/home/me/workspace/myapp//MainApplication.java:3: error: package javafx.application does not exist
import javafx.application.Platform;
                         ^
/home/me/workspace/myapp//MainApplication.java:4: error: package javafx.beans.property does not exist
import javafx.beans.property.BooleanProperty;
                            ^

Savez-vous si j'ai fait quelque chose de mal?

Alors, comment les gens ajoutent-ils JavaFX à leur AdoptOpenJDK sur Linux, à savoir les dérivés Ubuntu/Debian ? Je le vois mentionné dans ce fil, mais je ne suis pas un expert en construction, pour le relever à partir de petits indices et mentions.

Alors, comment les gens ajoutent-ils JavaFX à leur AdoptOpenJDK sur Linux, à savoir les dérivés Ubuntu/Debian ? Je le vois mentionné dans ce fil, mais je ne suis pas un expert en construction, pour le relever à partir de petits indices et mentions.

Vous devez avoir installé OpenJDK 8 et OpenJFX 8.

Installer OpenJDK 8

sudo apt-get install openjdk-8-jdk

Installer OpenJFX 8
Ouvrir le fichier sources.list
cd /etc/apt sudo nano sources.list
Collez ceci dans le fichier et enregistrez et fermez
deb http://de.archive.ubuntu.com/ubuntu/ bionic universe

Exécutez ce code dans le terminal
sudo apt-get update sudo apt install openjfx=8u161-b12-1ubuntu2 libopenjfx-java=8u161-b12-1ubuntu2 libopenjfx-jni=8u161-b12-1ubuntu2 openjfx-source=8u161-b12-1ubuntu2
Puis
sudo apt-mark hold libopenjfx-java libopenjfx-jni openjfx openjfx-source

Il y a aussi Liberica, qui contient FX.
https://bell-sw.com/pages/java-8u232/

@rafik777 , comment pouvez-vous dire qu'il contient des FX ? Je recherche principalement quelque chose sur lequel JavaFX est préinstallé afin de pouvoir créer mon ancienne application Java. Mais quand je l'ai construit avec gradle en utilisant une image Docker bellsoft/liberica-openjdk-debian:8 , il a signalé un tas d'erreurs
Savez-vous si j'ai fait quelque chose de mal?

@thaiphv Je pense que vous devriez créer votre propre image Docker à partir de ce Dockerfile :

https://github.com/bell-sw/Liberica/blob/master/docker/repos/liberica-openjdk-debian/8/Dockerfile

mais change ça
ARG LIBERICA_USE_LITE=1
à
ARG LIBERICA_USE_LITE=0

@thaiphv Je pense que vous devriez créer votre propre image Docker à partir de ce Dockerfile :

https://github.com/bell-sw/Liberica/blob/master/docker/repos/liberica-openjdk-debian/8/Dockerfile

mais change ça
ARG LIBERICA_USE_LITE=1
à
ARG LIBERICA_USE_LITE=0

@rafik777 , merci pour la suggestion. Je vais essayer.

J'utilise Mac OS Catalina. J'exécutais mon projet sur adoptopenjdk11 avec le plugin org.openjfx.javafxplugin . Malheureusement, j'ai rencontré un problème de sécurité qui empêche OpenCV d'accéder à ma webcam, ce qui a provoqué le plantage d'OpenJDK 11. Je n'ai pas trouvé de solution au problème de sécurité.

J'ai ensuite décidé d'installer adoptopenjdk8 pour voir si cela provoquerait un crash similaire. Malheureusement, j'ai découvert que org.openjfx.javafxplugin ne peut pas être utilisé avec OpenJDK 8, puis j'ai atteint ce sujet pour découvrir que JavaFX n'est pas fourni avec OpenJDK 8.

Je cherche actuellement à compiler org.openjfx.javafxplugin contre OpenJDK 8 (https://github.com/openjfx/javafx-gradle-plugin/issues/61).

Alors, des avancées là-dessus ? De plus, si quelqu'un a une solution de contournement pour Mac OS Catalina, les commentaires sont très appréciés.

Je pense qu'il est clair maintenant que le projet AdoptOpenJDK n'a aucun intérêt à nous aider avec nos problèmes JavaFX.

La seule véritable voie à suivre est de supprimer AdoptOpenJDK. Avez-vous essayé le JDK Liberica de bell-sw.com ? C'est la seule distribution que j'ai trouvée qui coche toutes les cases.

La situation n'a pas changé depuis que j'ai commenté la dernière fois (et je ne parle pas au nom du TSC) : OpenJFX 8 n'est actuellement pas maintenu. Et nous ne sommes pas disposés à créer et à distribuer quelque chose qui contient des vulnérabilités de sécurité connues. Agir ainsi serait une négligence grave.

Les membres d'AdoptOpenJDK ont contacté Azul et Bell Soft pour collaborer sur OpenJFX 8. Ces efforts n'ont pas été couronnés de succès pour des raisons que je ne connais pas. Nous prévoyons toujours de construire et de distribuer OpenJFX 11, mais nous manquons de personnel.

AdoptOpenJDK est un projet de bénévoles. Très peu de personnes sont payées par les sponsors et elles travaillent généralement dans les domaines qui intéressent le plus les sponsors. OpenJFX n'est apparemment pas l'un d'entre eux. Si vous voulez voir des progrès dans un domaine, faites du bénévolat ou parrainez l'effort.

Vous pouvez utiliser cette image docker, elle contient javafx, en fait, j'exécute cette version, elle fonctionne bien.

amazo ncorretto:8

https://hub.docker.com/_/amazoncorretto

Supplémentaires peuvent définir ces lignes dans le Dockerfile :
apt-get update && \
apt-get install -y —no-install-recommends imagemagick openjfx git \
&& rm -rf /var/lib/apt/lists/*

@chilcho1939
OpenJFX dans Amazon Corretto 8 n'a pas été mis à jour depuis longtemps.
Si vous cochez javafx.properties , vous pouvez comprendre.
De plus, OpenJFX n'est pas inclus dans Corretto 11.
https://github.com/corretto/corretto-11/issues/1

Au lieu de cela, je vous recommande d'utiliser Liberica JDK.

Dans l'état actuel des choses, il est hautement improbable qu'AdoptOpenJDK regroupe OpenJFX. Pour savoir pourquoi, ce qu'il faudrait pour le changer et quelles sont les alternatives, veuillez consulter notre FAQ sur OpenJFX .

Alors, comment les gens ajoutent-ils JavaFX à leur AdoptOpenJDK sur Linux, à savoir les dérivés Ubuntu/Debian ? Je le vois mentionné dans ce fil, mais je ne suis pas un expert en construction, pour le relever à partir de petits indices et mentions.

Vous devez avoir installé OpenJDK 8 et OpenJFX 8.

Installer OpenJDK 8

sudo apt-get install openjdk-8-jdk

Installer OpenJFX 8
Ouvrir le fichier sources.list
cd /etc/apt sudo nano sources.list
Collez ceci dans le fichier et enregistrez et fermez
deb http://de.archive.ubuntu.com/ubuntu/ bionic universe

Exécutez ce code dans le terminal
sudo apt-get update sudo apt install openjfx=8u161-b12-1ubuntu2 libopenjfx-java=8u161-b12-1ubuntu2 libopenjfx-jni=8u161-b12-1ubuntu2 openjfx-source=8u161-b12-1ubuntu2
Puis
sudo apt-mark hold libopenjfx-java libopenjfx-jni openjfx openjfx-source

Très difficile à faire dans la version Debian Buster, malheureusement. Le paquet jni a besoin d'un tas de dépendances qui ne sont même plus disponibles.

root@DESKTOP-8N43UKC:/etc/apt# apt install openjfx=8u161-b12-1ubuntu2 libopenjfx-java=8u161-b12-1ubuntu2 libopenjfx-jni=8u161-b12-1ubuntu2
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libopenjfx-jni : Depends: libavcodec57 (>= 7:3.4.2) but it is not going to be installed or
                           libavcodec-extra57 (>= 7:3.4.2) but it is not going to be installed
                  Depends: libavformat57 (>= 7:3.4.2) but it is not going to be installed
                  Depends: libgtk2.0-0 (>= 2.24.0) but it is not going to be installed
                  Depends: libjpeg8 (>= 8c) but it is not installable
                  Depends: libxslt1.1 (>= 1.1.25) but it is not going to be installed
 openjfx : Depends: openjdk-8-jre but it is not going to be installed

J'ai mis à jour mes téléchargements pour JavaFX-Overlay.
https://benjamin-brummer.de/downloads/
De plus, j'ai ajouté un téléchargement pour les Windows-Dlls nécessaires.
Vous pouvez soit télécharger l'Overlay + les Dll et le copier sur votre AdoptOpenJDK existant, soit télécharger les fichiers AIO-Zip.

est-ce compatible avec AdoptOpenJDK11 ?

Pour installer sur Open JDK 8
sudo apt installer openjfx=8u161-b12-1ubuntu2 libopenjfx-java=8u161-b12-1ubuntu2 libopenjfx-jni=8u161-b12-1ubuntu2

Alors, comment les gens ajoutent-ils JavaFX à leur AdoptOpenJDK sur Linux, à savoir les dérivés Ubuntu/Debian ?

Vous pouvez utiliser mon dépôt qui contient OpenJFX8 avec tous les correctifs ojdkbuild :
https://github.com/jschwartzenberg/openjfx8

Assurez-vous d'avoir un OpenJDK 8 récent et faites un clone git du référentiel et utilisez sh ./gradlew zips pour construire le zip de superposition.

Toute autre version d'OpenJFX8 que j'ai vue présente des failles de sécurité connues.

apt-mark hold libopenjfx-java libopenjfx-jni openjfx openjfx-source

@samikrc - https://askubuntu.com/a/1062168 aidé.

J'ai mis à jour mes téléchargements pour JavaFX-Overlay.
https://benjamin-brummer.de/downloads/
De plus, j'ai ajouté un téléchargement pour les Windows-Dlls nécessaires.
Vous pouvez soit télécharger l'Overlay + les Dll et le copier sur votre AdoptOpenJDK existant, soit télécharger les fichiers AIO-Zip.

Salut... Avez-vous une superposition mise à jour ? Windows x64

Salut... Avez-vous une superposition mise à jour ? Windows x64

Pour Windows, je recommande les builds de https://github.com/ojdkbuild/ojdkbuild

Salut... Avez-vous une superposition mise à jour ? Windows x64

Pour Windows, je recommande les builds de https://github.com/ojdkbuild/ojdkbuild

Salut, peut-être qu'il me manque quelque chose par où se trouvent les superpositions JFX dans ce repo ?

Salut, peut-être qu'il me manque quelque chose par où se trouvent les superpositions JFX dans ce repo ?

Il dans chaque version, voir par exemple :
https://github.com/ojdkbuild/ojdkbuild/releases/tag/java-1.8.0-openjdk-1.8.0.275-1.b01

Je ne sais pas si ces superpositions fonctionnent également avec les binaires d'Adopter. Je ne connais pas les avantages des binaires Adopt.

@wicadmin @jschwartzenberg
Bonjour, je pense que vous feriez mieux d'utiliser Liberica JDK[1] ou ZuluFX[2].
Voir la FAQ[3] d'AdoptOpenJDK.
Je recommande Liberica JDK !

Liberica et ZuluFX n'offrent pas de superpositions.
Si vous en avez besoin, vous pouvez peut-être télécharger le SDK de Gluon[4].
Mais Gluon ne propose pas de version JavaFX 8 et LTS gratuitement.
De plus, ZuluFX n'offre pas OpenJFX LTS[5], à l'exception de Zulu 8.

[1] https://bell-sw.com/pages/downloads/?package=jdk-full
[2] https://www.azul.com/downloads/zulu-community/?package=jdk-fx
[3] https://adoptopenjdk.net/faq.html#openjfxfaq
[4] https://gluonhq.com/products/javafx/
[5] https://docs.azul.com/zulu/zulurelnotes/ZuluReleaseNotes/ReleaseDetails1528-1335-1334-1143-1142-850-849-742-741-636-respin.htm

@wicadmin nous sommes passés à Amazon Coretto https://aws.amazon.com/corretto/

J'ai essayé chacun d'entre eux. Certains ont d'anciens composants JFX. Je suis coincé avec Java 8 pour notre application. En raison d'un problème quelconque avec les composants JFX dans Oracle ( l' application ne répond plus ), nous avons passés à AdoptOpenJDK 8 et tout fonctionne avec @benbrummer superposition excepter jfxwebkit.dll donnant cette erreur:

java.lang.UnsatisfiedLinkError: com.sun.webkit.WebPage.twkUpdateRendering(J)V
at com.sun.webkit.WebPage.twkUpdateRendering(Native Method)
at com.sun.webkit.WebPage.updateRendering(WebPage.java:648)
at com.sun.webkit.WebPage.updateContent(WebPage.java:641)
at com.sun.javafx.sg.prism.web.NGWebView.update(NGWebView.java:74)
at javafx.scene.web.WebView.handleStagePulse(WebView.java:999)
at javafx.scene.web.WebView.lambda$new$0(WebView.java:280)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:399)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:398)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:422)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:518)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:498)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:491)
at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:319)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$null$3(WinApplication.java:177)
at java.lang.Thread.run(Thread.java:748)

jfxwebkit.dll d'autres distributions semble maintenant résoudre ce problème, mais maintenant je ne sais pas ce qui manque car il s'agit d'une taille légèrement plus petite que celle de @benbrummer .

@benbrummer
JavaFX dans Corretto est une très ancienne version "8u202".
Et il n'est pas pris en charge dans Corretto 11[1].
Donc, je pense qu'il ne devrait pas être utilisé.

[1] https://github.com/corretto/corretto-11/issues/1

@wicadmin @jschwartzenberg
Bonjour, je pense que vous feriez mieux d'utiliser Liberica JDK[1] ou ZuluFX[2].
Voir la FAQ[3] d'AdoptOpenJDK.
Je recommande Liberica JDK !

Savez-vous quels correctifs incluent ZuluFX ? La dernière fois que j'ai vérifié, ils n'avaient pas publié leurs sources le long des binaires et il fallait leur demander des frais de transfert.
J'ai eu un appel positif avec BellSoft concernant les correctifs qu'ils utilisent pour LibericaFX 8 et s'ils peuvent fournir un aperçu de ceux-ci. Je ne sais pas s'ils ont déjà réussi à mettre cela en place.

@wicadmin nous sommes passés à Amazon Coretto https://aws.amazon.com/corretto/

Comme mentionné, la version d'OpenJFX 8 incluse avec Corretto est ancienne et présente des vulnérabilités connues. Leur version manque également de support WebKit. J'ai créé des PR il y a quelque temps, mais ils les ignorent essentiellement.

J'ai essayé chacun d'entre eux. Certains ont d'anciens composants JFX. Je suis coincé avec Java 8 pour notre application.

Quels problèmes avez-vous rencontrés avec les versions du projet ojdkbuild ? La raison pour laquelle j'ai basé mon référentiel OpenJFX 8 sur ojdkbuild est que j'avais besoin de versions non Windows à jour et que je voulais avoir un aperçu de tous les correctifs inclus. Aucune des autres versions ne pouvait satisfaire cela à l'époque.

Si quelqu'un souhaite qu'AdoptOpenJDK fournisse des versions avec OpenJFX 8 (ou une version plus récente), nous serons heureux de le faire si un contributeur crédible de correctifs s'intensifie et sait ce qu'il fait. Fournir des builds est facile, mais pas garder OpenJFX 8 à jour.

Si quelqu'un souhaite qu'AdoptOpenJDK fournisse des versions avec OpenJFX 8 (ou une version plus récente), nous serons heureux de le faire si un contributeur crédible de correctifs s'intensifie et sait ce qu'il fait. Fournir des builds est facile, mais pas garder OpenJFX 8 à jour.

Quels sont les avantages des versions AdoptOpenJDK ? Pour les utilisateurs de Windows, je signale le projet ojdkbuild (qui a un ingénieur RedHat derrière lui). Pour les utilisateurs non Windows, le gestionnaire de packages de leur système d'exploitation dispose généralement de la meilleure version OpenJDK.

Sur la base du travail ojdkbuild, je construis une variante OpenJDK avec OpenJFX 8 en utilisant les sources RedHat. Qu'est-ce que le changement ou la fourniture de builds à l'aide d'Adopt me rapporterait ?

Pour les utilisateurs de Windows, je signale le projet ojdkbuild (qui a un ingénieur RedHat derrière lui).

Nous avons une douzaine (environ) d'ingénieurs Red Hat :wink:

Pour les utilisateurs non Windows, le gestionnaire de packages de leur système d'exploitation dispose généralement de la meilleure version OpenJDK.

[citation requise]

Je suis d'accord pour les saveurs Red Hat. Les paquets de Debian et ses variantes ont eu des problèmes historiquement, en particulier autour de JPMS et jpackage.

Sur la base du travail ojdkbuild, je construis une variante OpenJDK avec OpenJFX 8 en utilisant les sources RedHat. Qu'est-ce que le changement ou la fourniture de builds à l'aide d'Adopt me rapporterait ?

Si vous êtes satisfait de ce que vous avez, c'est parfait, surtout si vous aimez créer vous-même OpenJDK. Je voulais seulement noter que nous ne sommes pas contre l'offre d'OpenJFX 8 mais que nous ne l'avons pas fait dans le passé car nous n'avons trouvé personne capable de le maintenir. Et si quelqu'un se porte volontaire, nous serons heureux d'offrir l'aide nécessaire.

Nous avons une douzaine (environ) d'ingénieurs Red Hat

C'est bon à savoir :) Peut-être pourriez-vous aussi accompagner celui qui se cache derrière le travail de @ojdkbuild ?

_[citation requise]_

Je suis d'accord pour les saveurs Red Hat. Les paquets de Debian et ses variantes ont eu des problèmes historiquement, en particulier autour de JPMS et jpackage.

Je n'ai jamais rencontré de problèmes en faisant yum / apt / pacman /etc. installations de l'OpenJDK. S'il y a des problèmes perçus avec les paquets Debian, a-t-il été envisagé de contribuer directement à les améliorer ?

Si vous êtes satisfait de ce que vous avez, c'est parfait, surtout si vous aimez créer vous-même OpenJDK. Je voulais seulement noter que nous ne sommes pas contre l'offre d'OpenJFX 8 mais que nous ne l'avons pas fait dans le passé car nous n'avons trouvé personne capable de le maintenir. Et si quelqu'un se porte volontaire, nous sommes heureux d'offrir l'aide nécessaire

Mon argument est que je ne vois aucun avantage à introduire OpenJFX dans AdoptOpenJDK car je ne suis pas au courant des avantages des binaires Adopt. Comme vous le voyez ci-dessus, il y a des demandes pour fournir OpenJFX pour Windows. Ceci est facilement disponible dans un projet différent, qui est moins connu avec Adopt suggérant principalement d'adopter ses propres binaires.

Qu'est-ce qui serait perdu si Adopt arrêtait de fournir des binaires Windows et dirigeait les utilisateurs vers le projet ojdkbuild à la place ? Au moins, cela leur permettrait de prendre en charge OpenJFX.

S'il y a des problèmes perçus avec les paquets Debian, a-t-il été envisagé de contribuer directement à les améliorer ?

Pas vraiment. Faire correctement les paquets Debian est difficile et si les responsables des paquets ne peuvent pas le comprendre eux-mêmes, il est peu probable que nous le puissions. En plus de cela, la politique de publication des distributions Linux ne fonctionne pas bien avec le calendrier OpenJDK (vous pouvez avoir AdoptOpenJDK 15 qui s'exécute sur Ubuntu Xenial). Il est alors presque impossible de remplir les exigences JCP dans le contexte d'une distribution OSS Linux. On y arrive petit à petit sans les contraintes des autres.

Ceci est facilement disponible dans un projet différent, qui est moins connu avec Adopt suggérant principalement d'adopter ses propres binaires.

C'est tout à fait correct d'utiliser cela en vertu de la disposition c'est à jour (ou vous savez ce que vous faites). Si les entreprises clientes demandent Java avec JavaFX 8, je les renvoie vers Oracle JDK.

Qu'est-ce qui serait perdu si Adopt arrêtait de fournir des binaires Windows et dirigeait les utilisateurs vers le projet ojdkbuild à la place ? Au moins, cela leur permettrait de prendre en charge OpenJFX.

Je ne peux pas vraiment commenter cela parce que je ne connais pas le projet ojdkbuild. Notre mission est d'offrir des versions binaires OpenJDK de haute qualité qui correspondent le plus possible à OpenJDK et peuvent être utilisées sans restrictions d'utilisation sur un large éventail de plates-formes. Si tous les autres fournisseurs arrêtaient de publier leurs JDK, nous serions toujours là et offririons une alternative gratuite à Oracle JDK. Si les gens préfèrent utiliser autre chose (Liberica, SapMachine, ...), ça me va. Nous proposons même plusieurs JDK nous-mêmes avec Dragonwell bientôt à bord et nous effectuons l'assurance qualité pour Amazon Corretto. AdoptOpenJDK concerne moins les versions binaires elles-mêmes que le fait d'être un foyer pour les versions OpenJDK et les projets associés qui disposent des ressources nécessaires (infra, personnes, argent).

Pas vraiment. Faire correctement les paquets Debian est difficile et si les responsables des paquets ne peuvent pas le comprendre eux-mêmes, il est peu probable que nous le puissions.

Ensuite, je suis curieux de savoir quels problèmes sont perçus car le fait est qu'une version prise en charge de Debian/Ubuntu permet d'installer OpenJDK directement à partir de leurs référentiels et vous obtenez la dernière mise à jour pour les versions LTS (8 et 11). Nous devons faire attention à éviter de discuter de problèmes qui pourraient ne pas être là.

Si les entreprises clientes demandent Java avec JavaFX 8, je les renvoie vers Oracle JDK.

Cela ne vous donnera pas de sources ni d'informations réelles, vous perdez donc certains avantages d'OpenJDK. Sauf erreur et qu'Oracle fournit le code source de leurs builds ? Les binaires avec des instructions correspondantes pour les compiler à partir des sources sont l'un des plus grands avantages de l'OpenJDK.

Notre mission est d'offrir des versions binaires OpenJDK de haute qualité qui correspondent le plus possible à OpenJDK et peuvent être utilisées sans restrictions d'utilisation sur un large éventail de plates-formes.

Il n'y a pas de builds OpenJDK avec des restrictions d'utilisation. Il s'agit d'une simple conséquence de la GPL qui offre la liberté d'utiliser le logiciel à n'importe quelle fin.

AdoptOpenJDK concerne moins les versions binaires elles-mêmes que le fait d'être un foyer pour les versions OpenJDK et les projets associés qui disposent des ressources nécessaires (infra, personnes, argent).

C'est vraiment super. Mais alors ce serait en effet une idée de promouvoir des builds provenant d'autres sources aussi ? Peut-être que cela pourrait être aussi simple qu'une entrée de FAQ avec "Qu'en est-il d'OpenJFX?" et en pointant vers une liste d'alternatives qui le regroupent (avec une note que vous ne pouvez pas vous porter garant de ces versions). Il pourrait également s'agir d'une vue d'ensemble plus élaborée incluant les services d'assurance qualité.

Ensuite, je suis curieux de savoir quels problèmes sont perçus car le fait est qu'une version prise en charge de Debian/Ubuntu permet d'installer OpenJDK directement à partir de leurs référentiels et vous obtenez la dernière mise à jour pour les versions LTS (8 et 11).

Par exemple : https://bugs.launchpad.net/ubuntu/+source/openjdk-14/+bug/1868699

Cela ne vous donnera pas de sources ni d'informations réelles, vous perdez donc certains avantages d'OpenJDK.

Oui, mais à ma connaissance, c'est le seul fournisseur qui a un Java FX 8 entièrement patché et le fera jusqu'en 2022. La plupart des gens ne se soucient pas de pouvoir compiler à partir des sources.

Il n'y a pas de builds OpenJDK avec des restrictions d'utilisation. Il s'agit d'une simple conséquence de la GPL qui offre la liberté d'utiliser le logiciel à n'importe quelle fin.

Tu interprètes mal ce que j'ai écrit. OpenJDK est un projet source uniquement (principalement). Nous sommes là pour nous assurer qu'il existe au moins une version binaire OpenJDK.

Peut-être que cela pourrait être aussi simple qu'une entrée de FAQ avec "Qu'en est-il d'OpenJFX?" et en pointant vers une liste d'alternatives qui le regroupent (avec une note que vous ne pouvez pas vous porter garant de ces versions).

https://adoptopenjdk.net/faq.html#openjfxfaq

Ensuite, je suis curieux de savoir quels problèmes sont perçus car le fait est qu'une version prise en charge de Debian/Ubuntu permet d'installer OpenJDK directement à partir de leurs référentiels et vous obtenez la dernière mise à jour pour les versions LTS (8 et 11).

Par exemple : https://bugs.launchpad.net/ubuntu/+source/openjdk-14/+bug/1868699

Merci! Cela permet de mieux comprendre pourquoi il y a Adopt :)

Oui, mais à ma connaissance, c'est le seul fournisseur à disposer d'un Java FX 8 entièrement patché et le fera jusqu'en 2022.

https://adoptopenjdk.net/faq.html#openjfxfaq

Joli!! Peut-être pourriez-vous aussi pointer vers https://github.com/ojdkbuild/ojdkbuild ? L'intention est jusqu'en mai 2026.

La plupart des gens ne se soucient pas de pouvoir compiler à partir des sources.

Citation requise ;)

Joli!! Peut-être pourriez-vous aussi pointer vers https://github.com/ojdkbuild/ojdkbuild ? L'intention est jusqu'en mai 2026.

Est openjfx-8.0.202-1.b15.ojdkbuild.windows.x86_64.zip (source : https://github.com/ojdkbuild/ojdkbuild/releases/tag/java-1.8.0-openjdk-1.8.0.275-1 .b01) qu'est-ce que c'est ? Ce serait inquiétant. Ou demander différemment : où puis-je trouver plus d'informations sur les correctifs qui ont été appliqués ?

Où puis-je trouver plus d'informations sur les correctifs appliqués ?

Tous les correctifs sont ici : https://github.com/ojdkbuild/upstream_openjfx-8u

Cependant, cet arbre ne s'appuie que sur Windows. Il manque également l'histoire originale. Ainsi, lorsque j'ai posé des questions sur la prise en charge de GNU/Linux, on m'a suggéré qu'il serait préférable de réimporter le référentiel Mercurial avec son historique et de mettre les correctifs pertinents en haut.
https://github.com/ojdkbuild/ojdkbuild/issues/87#issuecomment -502648409

Comme il semblait que personne ne faisait ça, je l'ai fait moi-même :
https://github.com/jschwartzenberg/openjfx8

J'ai ajouté quelques correctifs supplémentaires tels que celui pour le faire compiler sur les distributions avec une glibc plus récente. Ce référentiel doit être compilé sur au moins RHEL6 (et supérieur) et les versions récentes de Fedora.

Le jfxwebkit.dll semble bogué. La version

Le jfxwebkit.dll semble bogué. La version

Combinez-vous la superposition avec la version Adopt ou utilisez-vous la version complète de ojdkbuild ? Dans ce dernier cas, je suggérerais de signaler un problème dans le suivi des problèmes ojdkbuild. De préférence avec un cas de test. D'après mon expérience, WebView via WebKit fonctionne bien avec les versions ojdkbuild.

Le jfxwebkit.dll semble bogué. La version

Combinez-vous la superposition avec la version Adopt ou utilisez-vous la version complète de ojdkbuild ? Dans ce dernier cas, je suggérerais de signaler un problème dans le suivi des problèmes ojdkbuild. De préférence avec un cas de test. D'après mon expérience, WebView via WebKit fonctionne bien avec les versions ojdkbuild.

Oui, j'ai utilisé ojdkbuild et superposé le jfx d'ojdkbuild.

Seuls les éléments jfx concernant webview/webkit semblent mieux fonctionner compilés autour des versions 232 (de benbrummer) d'openjdk mais donnent cette erreur :

java.lang.UnsatisfiedLinkError: com.sun.webkit.WebPage.twkUpdateRendering(J)V

À moins qu'un nettoyage majeur n'ait été effectué, nous parlons d'une différence de 6 Mo dans la taille du jfxwebkit.DLL (l'ojdkbuild étant 6 Mo de moins que celui de @benbrummer .

Je me demande si cette vérification de l'ajout du fil d'événement sur ce correctif est à l'origine du processus javaw.exe qui ne répond pas dans Windows ?
https://github.com/jschwartzenberg/openjfx8/commit/5ec80a12039b73c1d27fcab9bde17b4b6852516c#diff -ddb457cb213b5c9647b2d6ed7ac555851c162cddd5c0ea2a371973755edd75cd

Oui, j'ai utilisé ojdkbuild et superposé le jfx d'ojdkbuild.

J'ai moi-même effectué la plupart des tests sur Windows avec 8u222. Peut-être pourriez-vous voir si les anciennes versions fonctionnent mieux.

À moins qu'un nettoyage majeur n'ait été effectué, nous parlons d'une différence de 6 Mo dans la taille du jfxwebkit.DLL (l'ojdkbuild étant 6 Mo de moins que celui de @benbrummer .

Je soupçonne que cela est dû à la façon dont la compilation est effectuée et celle de @benbrummer a plus de bibliothèques liées de manière statique. Celui de @ojdkbuild semble utiliser la liaison dynamique et comprend quelques DLL supplémentaires.

Je me demande si cette vérification de l'ajout du fil d'événement sur ce correctif est à l'origine du processus javaw.exe qui ne répond pas dans Windows ?
jschwartzenberg/ openjfx8@5ec80a1#diff -ddb457cb213b5c9647b2d6ed7ac555851c162cddd5c0ea2a371973755edd75cd

Si vous pouviez identifier le problème à une régression commençant par une version particulière et signaler un ticket, je suppose que cela serait déjà très utile pour résoudre ce problème.

La version Windows d'OpenJFX est plutôt compliquée (IMO). Si vous avez une option GNU/Linux à tester et que le problème y est reproductible, il serait plus facile d'identifier le commit exact. Je pourrais alors vous aider si vous rencontrez des difficultés pour construire l'overlay OpenJFX à partir de mon référentiel.

J'ai moi-même effectué la plupart des tests sur Windows avec 8u222. Peut-être pourriez-vous voir si les anciennes versions fonctionnent mieux.

Oui, je viens de tester le JRE odjkbuild avec odkjbuild openjfx 8 et n'ai échangé que le jfxwebkit.dll de @benbrummer et je semble avoir un succès complet.

Je soupçonne que cela est dû à la façon dont la compilation est effectuée et celle de @benbrummer a plus de bibliothèques liées de manière statique. Celui de @ojdkbuild semble utiliser la liaison dynamique et comprend quelques DLL supplémentaires.

Peut-être que, quoi que ce soit, cela semble faire la différence lorsqu'il est compilé statiquement.

La version Windows d'OpenJFX est plutôt compliquée (IMO). Si vous avez une option GNU/Linux à tester et que le problème y est reproductible, il serait plus facile d'identifier le commit exact. Je pourrais alors vous aider si vous rencontrez des difficultés pour construire l'overlay OpenJFX à partir de mon référentiel.

Malheureusement, il s'agit d'une application Windows uniquement. Je vais cependant voir comment il fonctionne sous Linux.

Peut-être que, quoi que ce soit, cela semble faire la différence lorsqu'il est compilé statiquement.

Ou c'est la différence de version. WebKit a beaucoup changé entre les mises à jour, de nouvelles versions de WebKit (correction des vulnérabilités) ont également été introduites.

Malheureusement, il s'agit d'une application Windows uniquement. Je vais cependant voir comment il fonctionne sous Linux.

L'objectif de ces technologies serait que le même logiciel puisse s'exécuter sur n'importe quelle plate-forme prise en charge par l'environnement d'exécution. Ça devrait être intéressant de voir si ça marche !

S'il y a une mise à jour de la documentation que nous pouvons apporter au blog ou au site Web, les relations publiques sont les bienvenues.

Cette page vous a été utile?
0 / 5 - 0 notes