Commentaires

Merci, ça aide vraiment ! Surtout quand on ne sait pas vers quoi se diriger !

Envoyé par prisme60

Bonjour,

Dans mon entreprise, on fait de l'intégration continue (compilation, et génération jLink) avec Maven. Pour la packaging, celui-ci est fait en dehors (compilation c++ et rpmbuild).

Est-ce qu'il est possible d'utiliser Maven (ou Graddle) dans le processus de génération JavaFx avec kotlin ?

Merci d'avance (c'est surtout pour être au courant dans le cadre d'un prochain projet).

Aucune idée, il faut tester. Maven a le soucis de ne pas vraiment bien s'intégrer dans nos sécurité réseau et de ne fonctionner qu'à moitié donc je n'ai jamais rien pu tester de concret de ce côté-là.
Les instructions pour JavaFX et Maven sont ici.
Et pour Kotlin, c'est par là.
Y a pu qu'à faire des test et tenter de faire un prototype...

PS : pas la peine de me poser la question pour Gradle, c'est pareil...

Bonjour,

Dans mon entreprise, on fait de l'intégration continue (compilation, et génération jLink) avec Maven. Pour la packaging, celui-ci est fait en dehors (compilation c++ et rpmbuild).

Est-ce qu'il est possible d'utiliser Maven (ou Graddle) dans le processus de génération JavaFx avec kotlin ?

Merci d'avance (c'est surtout pour être au courant dans le cadre d'un prochain projet).

Envoyé par doc

Merci pour ce tutoriel très didactique, ou tout est expliqué de a à z, de l'utilisation d'intelliJ à une brève introduction a l'utilisation de javaFx avec Kotlin.
La partie qui m'a vraiment intéressée concerne la création du fichier jar et du lanceur natif, m'étant maintes fois heurté a cette complication depuis l'utilisation des JDK > 1.8.
J'ai d'ailleurs relevé une petite erreur dans le fichier package.bat; celui-ci ne se trouvant pas à la racine du projet, la variable INPUT_DIR doit s'écrire comme ceci :
set INPUT_DIR=../out\artifacts\%APP_NAME%
Il me reste une interrogation surla création du jar lors de l’utilisation de bibliothèques modulaires et non modulairesdans le projet.

En fait, j'utilise le script depuis la racine du projet en faisant .\bin\nomduscript.bat donc le soucis ne se pose pas pour moi.

Merci pour ce tutoriel très didactique, ou tout est expliqué de a à z, de l'utilisation d'intelliJ à une brève introduction a l'utilisation de javaFx avec Kotlin.
La partie qui m'a vraiment intéressée concerne la création du fichier jar et du lanceur natif, m'étant maintes fois heurté a cette complication depuis l'utilisation des JDK > 1.8.
J'ai d'ailleurs relevé une petite erreur dans le fichier package.bat; celui-ci ne se trouvant pas à la racine du projet, la variable INPUT_DIR doit s'écrire comme ceci :
set INPUT_DIR=../out\artifacts\%APP_NAME%
Il me reste une interrogation surla création du jar lors de l’utilisation de bibliothèques modulaires et non modulairesdans le projet.

Oui c'est assez surprenant je trouve

Il est possible qu'ils aient assez de clients demandant un support commercial pour que ce soit viable. Ou alors ils ont du mal a adapter leurs autres produits a des versions plus récentes de Java... et je doute que leur SGBD puisse supporter une cadence de maj a vitesse grand V comme celle qu'ils nous imposent.

Merci Fabrice pour ce retour.

J'ai comme l'impression que Java 8 est encore très utilisé pour que Oracle recule la fin du support.

Mickael

Merci, je pensais qu'il s'agissait d'un soucis avec le lien dans ma news mais c'est en fait sur la page de garde de développez. Donc c'est du ressort de la rédaction / de l'équipe de publication et non pas du mien. Je vais transmettre au responsable de section.

Je confirme le problème de lien :

Sur la page https://java.developpez.com/ on a dans les actualités « Microsoft rejoint l'OpenJDK, la société derrière Windows contribue au développement du langage Java pour sa plateforme cloud Azure », avec pour url https://java.developpez.com/index/re...e-cloud-Azure/.
Quand je clique, j'arrive sur une page d'erreur qui me dit « Vous n'avez pas les droits nécessaires pour accéder à cette page ».

J'ai dû chercher le titre avec Google pour tomber sur l'url correct https://java.developpez.com/actu/282...e-cloud-Azure/.

Envoyé par ionel.cerp

Quand on clique sur le lien, on ne peut pas lire l'article directement.

Aucun soucis pour moi.

Quand on clique sur le lien, on ne peut pas lire l'article directement.

C'est une bonne nouvelle.
Il faut que je trouve le temps d'essayer ça car j'ai commencé à porter des applis 8 en 12 et en 8 il y a le javapackager.

Je trouve que fournir Java sans cela a été une erreur car dans le camp d'en face (Node), il y a des solutions qui fonctionnent (Electron) et choisies par Microsoft par exemple.
Java devrait se mettre au moins au même niveau de façon à ne plus se poser 15000 questions quand on veut faire une appli desktop en Java.

Nous avions eu quelques discussion avec la communauté à l'époque où la JEP 148 était créée, il était question d'avoir des applications Java ne nécessitant pas de machine avec une JRE pour fonctionner, et ne nécessitant pas d'embarquer un dossier contenant toute la JRE. GCJ étant obsolète, la JEP 148 semblait être une solution pouvant satisfaire ce besoin.

Je sais bien qu'il n'y a aucun rapport entre Golang, jshell et jpackage (je pourrais presque me sentir offensé par ta réponse ), c'était à titre de comparaison entre Java et la concurrence.

Salut,
il n’y a aucun rapport entre les deux JEP, il suffit de lire leur descriptif. Le but de la JEP 343 est de créer des lanceurs et installleurs/désinstalleur natifs tandis que celui de la JEP 148 est de réduire la taille de la JVM (encore plus qu’actuellement et ce pour les machines embarquées - small devices est mentionné dans la description). À la rigueur la JEP 148 semble se rapporter aux fonctionnalités de jlink et serait une optimisation supplémentaire sur ce que cet outil peut faire actuellement. Après en combinant les deux ben ça permet d’avoir des applications plus légères à distribuer.

Y a aucun rapport entre Golang, jshell et jpackage... ; le premier est un langage compilé, le deuxième est un environnement d’interprétation d’instructions écrites en Java et le troisième un outil de packaging... où as-tu bien pu chercher une telle idée...

Bonjour,

Quels sont les différences entre la JEP 148: Small VM et la JEP 343: Packaging Tool ? Je pensais que la JEP 148 avait pour objectif de créer des applications Java natives.

Est-ce que jpackage est une initiative pour concurrencer Golang ? (un peu comme comme jshell contre les langages de script)

Merci pour le billet

Une interview de Vos sur Jaxenter indique bien que le support Android est aussi dans les cartons

Il faut l'essayer !

Il manque une plateforme dans la liste . J.V. ne la mentionne pas, ... j'espère qu'elle arrivera rapidement.
J'avais testé le précédent plugin de Gluon sur Android mais, grosse déception, une partie de JavaFX-OpenJFX (Webkit) n'était pas opérationnelle.
C'est le WebView d'Android qui remplaçait le navigateur (Webkit) de JavaFX-OpenJFX et il ne disposait pas d'interface JavaScript (non implémentée) ou du support MathML.
Avec le nouveau plugin, c'est tout l'univers Java-OpenJDK/JavaFX-OpenJFX au complet qui arrive sur mobile. La version JavaFX-OpenJFX sera enfin la même pour toutes les plateformes.

Mais pas seulement !
Si je comprends bien c'est aussi tous les langages supportés par GraalVM, Java bien sûr, Python, ...

Merci Fabrice pour la news.

Ah si j'avais du temps pour tester, j'aimerais bien voir les possibilités de cette solution.

Mickael

Non ce tout premier billet a été fait sur fixe. Le second est en cours de rédaction sur mobile... et je crois bien que les suivants seront rédigés sur fixe à mon retour

Merci @bouye pour ce retour.

Tu veux dire que tu as écrit ce texte depuis un smartphone ? si c'est le cas respect ;-)

En attendant la suite

Mickael