Oracle introduit la création des packages natifs dans JavaFX 2.2

Oracle introduit la création des packages natifs dans JavaFX 2.2
permettant d’exécuter une application sans dépendances externes


Oracle a annoncé que JavaFX 2.2, sa solution pour la création d'applications internet riches (RIA), pourra être empaquetée en natif pour diverses plateformes.

Cette nouvelle possibilité permettra aux développeurs de créer des applications qui pourront être installées et exécutées sans nécessiter de dépendances externes comme JRE ou encore le SDK FX.

Le système "native package" pour les applications JavaFX fonctionne en créant un wrapper de votre application JavaFX, comprenant le code de l’application et les ressources, le runtime Java et JavaFX, le « launcher » d’application natif et autres métadonnées (icônes, etc).

La création des packages se fera via l'utilitaire en ligne de commande javafxpackager.

Le support de cette nouveauté est déjà intégré dans la Developer Preview de Java 7 Update 6 build 14 qui embarque JavaFX 2.2. Les autres mécanismes disponibles pour la publication des applications Java ne seront pas pour autant obsolètes.

Cette nouvelle possibilité sera disponible pour les applications exe et msi sous Windows, dmg sous Mac et enfin les programmes d’installation rpm et zip pour les systèmes Linux.

L’équipe de JavaFX espère également que ce nouveau système d’empaquetage en natif pourra être disponible pour les futures applications Java SE, construites avec Swing ou AWT.

En dehors de la taille du programme d’installation qui augmente à cause de l’inclusion du JRE et du SDK Java FX, un autre inconvénient de cette nouveauté est que les packages ne peuvent être créés que sur les plateformes ciblées.


Source : Oracle

La question que je me pose si ça serait possible de paramétrer qu'au cas où un JRE serait déjà installé de pouvoir choisir de ne pas installer la JRE et donné juste le répertoire ou bien que le programme le détecte automatiquement comme les autres application en Java s'il est indiqué dans le variables d’environnement, ce qui permettra d'optimiser la taille du programme d'installation.

En tout cas un déploiement en natif tout en un (servi comme du café) est une chose extrêmement intéressante pour les développeurs en Java. Car distribuer les application java était très simple(un simple .jar) mais pour faire un truc d'habitude pour un utilisateur lamda il fallait chercher un luncher et un installateur et commencer à faire tout à la manuellement, mais maintenant tout serait fait avec le JDK c'est une nouvelle qui m'a jouit vraiment quand je l'ai lu pour la première fois.

Citation:

---

Envoyé par la.lune

La question que je me pose si ça serait possible de paramétrer qu'au cas où un JRE serait déjà installé de pouvoir choisir de ne pas installer la JRE et donné juste le répertoire ou bien que le programme le détecte automatiquement comme les autres application en Java s'il est indiqué dans le variables d’environnement, ce qui permettra d'optimiser la taille du programme d'installation.

---

Ca m'étonnerait pas mal qu'ils offrent ce choix...

L'intérêt je pense est de pouvoir livrer justement livrer le programme avec la JRE sur laquelle tu as développé en standalone et ainsi justement s'affranchir de la dépendance sur le poste client et de la version de celle-ci.
En cela je doute qu'il soit possible d'opter pour un mix des deux (mode jre embarqué et mode jre client) car ça reviendrait à livrer 2 applications différentes. Cependant, c'est possible qu'un logiciel tiers style installshield permette de le faire moyennant un peu de configuration (déployeur minimal puis téléchargement d'une version ou l'autre).

Sinon l'idée est pas mal mais ce genre de produit existait déjà, il est déjà possible de bundler une jre avec son application et de démarrer avec un bootstrapper natif. Reste que c'est très bien que ce soit officiellement supporté pour les canaux de déploiement du style app market qui n'ont pas de gestion de dépendances centralisées.

J'ai déjà eu le cas du déploiement d'une application Java où les postes n'avais pas Java.
L'installateur lançait la mise à jour / installation de JRE. C'était dépendant d'une connexion internet, mais ça se passait bien.

Cordialement,
Patrick Kolodziejczyk.

Il y a une question que je me posais:

Est ce que on peut package plusieur applications .jar independante ensemble avec la meme JRE ?

edit:

Citation:

---

un autre inconvénient de cette nouveauté est que les packages ne peuvent être créés que sur les plateformes ciblées.

---

très dommage pour l'instant :(

Mouai, j'ai installe le JDK 1.7.0_06 b20 64bit*, j'ai modifié NB7.2 pour qu'il démarre sur ce JDK et défini une nouvelle plateforme Java utilisant ce JDK + les runtimes FX qu'il contient (apparemment FX 2.2 b18) et ai modifié mon projet pour qu'il repose sur cette plateforme et rajouté dans mon build.xml (comme indiqué ici) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<!-- FB : JavaFX - native packager builder - start --> <target name="-post-jfx-deploy"> <fx:deploy width="${javafx.run.width}" height="${javafx.run.height}" nativeBundles="all" outdir="${basedir}/${dist.dir}" outfile="${application.title}"> <fx:application name="${application.title}" mainClass="${javafx.main.class}"/> <fx:resources> <fx:fileset dir="${basedir}/${dist.dir}" includes="MFCL-viewer-j.jar"/> <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="MFCL-chart.jar"/> <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="MFCL-IO.jar"/> <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="OFP-core2.jar"/> <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="OFP-fx2.jar"/> <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="ScenicView.jar"/> </fx:resources> <fx:info title="${application.title}" vendor="${application.vendor}"/> </fx:deploy> </target> <!-- FB : JavaFX - native packager builder - end -->

---

Et j'ai droit a

Code:

---

1 2 3 4 5 6 7

Launching <fx:jar> task from C:\Program Files\Java\jdk1.7.0_06\lib\ant-javafx.jar Launching <fx:deploy> task from C:\Program Files\Java\jdk1.7.0_06\lib\ant-javafx.jar Using base JDK at: C:\Program Files\Java\jdk1.7.0_04\jre Skip [Windows Application Bundler] due to [Java Runtime does not include lib\jfxrt.jar] Skip [MSI Bundler (WiX based)] due to [Java Runtime does not include lib\jfxrt.jar] Skip [Exe Bundler (based on Inno Setup)] due to [Java Runtime does not include lib\jfxrt.jar]

---

Je me demande bien d’où il choppe qu'il doit utiliser le JDK 1.7.0_04...
Bref, c'est pas encore ça :aie:

*Ce qui au passage fait que SceneBuilder ne fonctionne plus car il ne reconnait pas le JRE 1.7.0_06 b20 64bit.

j'avais des soucis avec ça sous Linux.. va jeter un oeil dans ton fichier etc/netbeans.conf (dans le repertoire d'installation), t'as une variable netbeans_jdkhome qui te permet de définir le JDK par défaut... le probleme vient p'tet de là.

En tout cas, je sais que Netbeans 7.1, sous linux, utilise toujours ce JDK pour les projets Freeform, et ce même si tu modifies les propriétés de ton projet...

Teo

Non, j'ai fini par trouver que le JDK 1.70_04 était encore référencé malgré une désinstallation complète.

Au final, c’était un mix d'entre le fait que j'avais édité C:\Program Files (x86)\NetBeans 7.2\etc\netbeans.conf sans passer en admin et donc que
<mon compte>\appdata\local\virtual store\Program Files (x86)\NetBeans 7.2\etc\netbeans.conf referencait le JDK 1.70_06 tandis que C:\Program Files (x86)\NetBeans 7.2\etc\netbeans.conf referencait le JDK 1.70_04... et donc NetBeans utilisait alternativement soit l'un soit l’autre des JDK.
Stupide stupide Windows...

Donc après lecture du post blog et du guide de références et quelques tests (JDK 1.7.0_06 b21 + JFX 2.2 b19 qui est inclus dedans), j'ai pu rajouter une tache en fin de mon build.xml :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

<target name="-post-jfx-deploy"> <fx:deploy width="${javafx.run.width}" height="${javafx.run.height}" nativeBundles="all" embedJNLP="true" outdir="${basedir}/${dist.dir}" outfile="${application.title}"> <fx:application id="mainApplication" name="${application.title}" mainClass="${javafx.main.class}"/> <fx:info title="${application.title}" description="${application.desc}" vendor="${application.vendor}"> <fx:icon href="${basedir}/Hei_Matau.ico" kind="default" width="64" height="64" depth="32"/> </fx:info> <fx:platform id="mainPlatform" javafx="2.2" j2se="7.0"> <fx:jvmarg value="-server"/> <fx:jvmarg value="-XX:+UseG1GC"/> </fx:platform> <fx:resources> <fx:fileset dir="${basedir}/${dist.dir}" includes="MFCL-viewer-j.jar"/> <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="*.jar"/> </fx:resources> </fx:deploy> </target>

---

Ce qui produit le répertoire dist/bundle avec :

• Répertoire bundle
  
  • le fichier MSI (nécessite Wix sur le PATH sinon ce n'est pas généré). Dans mon cas 47Mo.
  • le setup wizard (nécessite Inno Setup sur le PATH sinon ce n'est pas généré). Dans mon cas 31Mo.
  • Répertoire <nom de l'application>
    
    • Un launcher natif Windows. Dans mon cas 97Ko.
    • son icône (actuellement l’icône par défaut 4Ko).
    • Répertoire app
      
      • le fichier de config du launcher package.cfg
        
        Code:

        ---

        1 2 3 4 5

        mainjar=OFP-fx2.jar version=null app.id=mainApplication jvmarg.1=-server jvmarg.2=-XX:+UseG1GC

        ---

      • Une copie de tous les JARs du projet (main jar + dépendances). Dans mon cas 1Mo.
    • Répertoire runtime
      
      • une copie complète du JRE + runtimes FX. Actuellement 139Mo sur Windows.

Tout n'est pas parfait cependant :

• Je déconseille de mettre tout de suite Wix et Inno setup dans le PATH (ou alors commenter la tache -post-jfx-deploy dans build.xml) car on passe alors de quelques secondes pour la compilation d'un (petit) projet (compilation + génération et compression des JAR + regroupement pour le bundle natif) a plus d'une minute (génération du MSI et du setup wizard et j'ai même pas encore rajouté la signature numérique). Ça devient donc assez lourdingue a chaque fois qu'on veut tester son app.
• Même si ma tache référence correctement des propriétés du projet NetBeans (${application.desc}, ${application.vendor}), elles semblent pour le moment être ignorées (voir le fichier package.cfg produit).
• Les arguments de la VM eux sont correctement inclus dans package.cfg.
• Le JNLP est généré correctement mais le launcher natif ne reçoit pas une bonne configuration : genre il a décrété que c'est un des JAR des dépendances qui devient le main jar de l'application et il insiste pour démarrer une classe qui est en fait un test dans cette même dépendance. Coté JNLP tout est décrit correctement par contre.
• Idem l’icône définie pour l'app ne vient pas remplacer celle fournie par défaut par le native bundler. Idem ici aussi tout est correct dans le JNLP.
• Dans les options de packaging du projet dans NetBeans j'ai demandé a ce que les JAR soient compressés (PACK200) mais c'est pas encore le cas apparemment.
• Idem contrairement a NetBeans 7.1 pour le moment je n'arrive plus avec cette config a pré-compiler les CSS de FX en binaire.

Faudra que je vois comment ca marche sous Linux et, pour le moment, je n'ai pas de MacOS sous la main pour voir comment ça marche (a noter qu'Oracle a poste ça concernant Mountain Lion qui se voit désormais dote d'une fonction GateKeeper qui semble marche de manière un peu similaire a l'UAC dans Windows).

Bref, c'est pas encore ça :aie:, et ça fait un peu gros pour une app qui fait a la base 1Mo. Dommage que la modularisation soit encore repoussée a Java 9.

En attendant, j'ai soumis le bug RT-23778 sur le Jira de JavaFX.

Citation:

---

Envoyé par bouye

En attendant, j'ai soumis le bug RT-23778 sur le Jira de JavaFX.

---

comme prévu, cela ne fonctionne pas correctement pour le moment quand on a plusieurs JAR contenant des JavaFX main-class dans le projet (NetBeans 7.0 et 7.1 avaient parfois des comportement similaire lorsque des projets JavaFX avaient de genre de dépendances également). Ce qui est d'autant plus gênant puisque NetBeans ne permet toujours pas de définir des JavaFX library (c-a-d des JAR sans application JavaFX dedans).