Convertir une application Java en exécutable EXE — Pourquoi?, Quand? et Comment?

Par Dmitry LESKOV LinkedIn

Dernière mise à jour: 09-Oct-2015
Également disponible en: anglais et allemand
Si vous êtes sûr que vous avez besoin d'un vrai fichier exécutable EXE, passez directement à Compilateurs AOT.

"Comment puis-je obtenir un fichier exécutable .EXE à partir de mon application Java?", "Besoin d'aide pour convertir un jar en EXE? ", "Est-il possible de créer un exécutable Windows en utilisant Java?" - Ceci et d'autres questions similaires sont parmi les sujets les plus populaires sur les forums de développeurs Java. Si vous commencez à vous questionner sur un tel sujet aujourd'hui même, vous êtes susceptible de rencontrer les trois types de réponses suivantes:

"Vous ne pouvez pas"

"Vous ne devriez pas, parce que ce serait aller à l'encontre du principe même de Java"

"Vous pouvez le faire avec des logiciels tiers X et Y"

La vérité est qu'il existe deux approches complètement différentes à la création d'un exécutable natif pour les applications Java, et ceux-ci s'adressent à un ensemble de problèmes distincts. Par ailleurs, sous certaines conditions, certains de ces problèmes peuvent être résolus sans passer par un fichier EXE. Donc, la meilleure façon de répondre à une telle question serait de demander plus d'informations, à savoir quel est le but de la conversion à EXE? Et la réponse la plus fréquente serait :

La compilation d'une application Java génère du bytecode indépendant de la plateforme (fichiers .class), mais non directement exécutable par la plateforme matérielle. Ainsi, un programme Java a besoin d'un environnement d'exécution Java (JRE) pour fonctionner, qui va soit interpréter les instructions en bytecode soit les compiler en code natif à la volée. Cela signifie que l'auteur d'un programme Java doit s’assurer qu'une version correcte du JRE soit présente sur le système de l'utilisateur.

En général vous ne pouvez pas vous attendre à ce que vos utilisateurs sachent ce qu’est un environnement d’exécution Java (JRE), comment vérifier sa version, comment le télécharger et l’installer. Cela est particulièrement vrai pour des applications telles que les jeux ou les applications multimédias. Par ailleurs, ceux qui ont déjà un JRE d’installé peuvent ne pas aimer l’idée d’installer une version différente, car cela peut compromettre la fiabilité de leurs applications Java existantes ou de leurs applets préférées.

Même si vous pouvez vous assurer que la bonne version JRE est correctement installée sur tous les systèmes cibles, ce qui est tout à fait possible dans un milieu scolaire ou d'entreprise par exemple, la ligne de commande nécessaire pour lancer votre application Java peut être assez fastidieuse à saisir :

java -Xmx200m -cp whatever.jar -Dsome.property MyApp

Certes, vous pouvez mettre cette ligne dans un fichier de commandes et l'appeler runme.bat, mais il semble tellement plus facile de donner votre programme à un ami, un enseignant ou un collègue dans un fichier unique qui peut être exécuté par un double-clic. Ou, mieux encore, lui permettre d'être installé et désinstallé de manière native sans affecter les autres applications.

Il n’est donc pas surprenant que la principale motivation pour la recherche d'un moyen de convertir une application Java en un fichier exécutable EXE soit en fait la recherche d'un moyen d'effectuer son déploiement de la façon la plus simple et la plus sûre pour l'utilisateur moyen, c'est-à-dire un utilisateur Windows. Ce qui surprend le développeur débutant en Java est que le JDK n’offre pas une telle fonctionnalité (sauf pour les applications JavaFX - Voir ci-dessous.) Avant le J2SE 1.4, tout ce que vous pouviez faire avec les outils JDK était des :

Si cet article vous semble trop long, vous pouvez directement consulter les ressources qui l'accompagnent: Best Jar to EXE Conversion Tools

Vous pouvez exécuter votre application Java via un double-clic en empaquetant le tout dans un fichier pseudo-exécutable, de type JAR exécutable. Cela se fait en spécifiant la classe principale de votre application et les fichiers jar supplémentaires qui sont nécessaires à son fonctionnement, dans un fichier manifeste :

Main-Class: MyAppMain
Class-Path: mylib.jar

Ensuite, il faut utiliser l'utilitaire jar du SDK Java pour empaqueter vos classes et les fichiers ressources, en spécifiant l'option m et le nom du fichier manifeste :

jar cvfm MyApp.jar MyApp.mf *.class *.gif

Cela entraînera la création de MyApp.jar. Maintenant, si vous tapez

java -jar MyApp.jar

le lanceur Java lira le manifeste de MyApp.jaret invoquera automatiquement la méthode main de la classe principale MyAppMain. Par ailleurs, si vous double-cliquez sur ce fichier jar sur un système qui a le JRE d’installé, le lanceur java sera appelé directement.

Remarque: Les fichiers JAR sont associés au lanceur javaw sur Windows, mais celui-ci n’ouvre pas de fenêtre console au démarrage. Si votre application a besoin d'une console, il faut créer un fichier batch qui démarrera celle-ci manuellement, en utilisant le lanceur java.

Si votre application se compose de plus d'un fichier jar, il y a un outil libre appelé One-JAR qui permet d'empaqueter correctement plusieurs fichiers jar en un seul.

Le problème majeur avec les jars exécutables est la compatibilité. En effet, le JRE par défaut peut être une version plus ancienne que celui qui est requis par votre application, ou peut ne pas disposer les paquetages optionnels Java nécessaires (anciennement connus sous le nom de Standard Extensions). Par exemple, si votre application utilise une ou plusieurs des plus récentes fonctionnalités du JDK 8 , elle ne fonctionnera pas sur JRE  7 ou toute autres version antérieure.

Heureusement, Sun Microsystems a créé une technologie de déploiement d'applications Java qui élimine ce problème de compatibilité et en y ajoutant par ailleurs quelques fonctionnalités intéressantes. Ceci fait partie de la plate-forme Java depuis la version 1.4 et est appelé:

Jars Exécutables

Avantages

Pas besoin d'utiliser des outils tiers

Distribution unique pour toutes les plates-formes compatibles Java

Désavantage

L'application ne démarre pas sur les systèmes qui n’ont pas de JRE (correctement) installé

L'application ne fonctionnera pas si elle utilise des API qui sont absents dans le JRE par défaut

Besoin d'enseigner aux utilisateurs que les fichiers jar sont cliquables

Ressources
Jar File Specification
Outils
One-JAR
Autojar
Fat Jar
Java Launcher

Java Web Start (JWS) et le protocole sous-jacent du Java Network Launch Protocol (JNLP) qui permet la livraison d'applications Java à partir d'un serveur Web standard. L'utilisateur amorce l’installation de l'application en cliquant sur un lien internet (URL). Si le moteur Java Web Start n’est pas présent sur le système, l'utilisateur est invité à le télécharger et à l'installer. Une fois que Java Web Start est en place et en re-cliquant sur la même URL, le téléchargement de l'application sera lancé, suivi des procédures d'installation. Ceci peut impliquer le téléchargement et l'installation de la version du JRE requise ainsi que des éventuels paquetages optionnels. Lorsque le tout est terminé avec succès, l'application est lancée. L'application sera mise en cache sur le système de l’utilisateur afin que la prochaine fois que celui-ci clique sur le même lien URL, le moteur JWS lance la copie locale de l'application, à condition que l'application n'ait pas été mise à jour sur le site Web, ou s'il détecte que l'ordinateur n'est pas en ligne.

Une autre caractéristique importante de JWS est sa capacité à exécuter votre application dans un environnement d'exécution sécurisé ( Sandbox). C'est un conteneur restreint basé sur l'architecture de sécurité Java. Mais, contrairement à une applet, après avoir invité l'utilisateur à le confirmer, votre application peut accéder aux ressources locales du système comme le système de fichiers, l’imprimante ou le presse-papiers en utilisant l'API JNLP même si celle-ci vient d'un environnement non sécurisé.

Java Web Start est inclus dans le JRE Oracle standard (pas dans le serveur JRE), avec des plug-ins pour les navigateurs populaires, bien que certains réglages de configuration du navigateur puissent être nécessaires. L'outil de paquetage JavaFX Packager peut également préparer l’application JavaFX pour déploiement via Java Web Start. Il existe aussi des implémentations tierces du protocole JNLP. Certaines d'entre elles intègrent des outils qui vous aident à la création et la maintenance des paquetages JNLP.

Ceci était pour les points positifs. Maintenant, qu'est-ce qui est moins séduisant à propos de JNLP? Tout d'abord, pour un fonctionnement sans faille, le navigateur et le serveur Web qui héberge l'application compatible JNLP doivent supporter les fichiers de type MIME application/x-java-jnlp-file. Certains fournisseurs d'hébergement ne le supportent pas. De plus, les mises à jour de versions incrémentielles doivent être supportées par le serveur Web, et qui doit être mis en œuvre en utilisant des servlets, des scripts cgi-bin, etc.

Du côté client, un navigateur populaire serait déjà configuré pour reconnaître le type MIME ci-dessus lors de l'installation du moteur JWS, mais les utilisateurs de navigateurs moins populaires, tels qu’Opéra, pourrait avoir à le faire manuellement.

Par ailleurs, rendre une application compatible JNLP peut impliquer des changements mineurs dans son code et un (re)paquetage des fichiers jar.

Avant J2SE 5.0, JWS avait très peu à offrir en termes d'intégration du bureau - tout ce qu'il pouvait faire était de créer une icône sur le bureau et/ou une entrée dans le menu Démarrer pour l'application. Sous Windows, l'application ne sera pas affichée dans Ajout/Suppression de programmes, de sorte que l’utilisateur devra exécuter le gestionnaire d'applications Java Web Start afin de supprimer l’application.

Enfin, l'interface utilisateur JWS a besoin d'améliorations. Nombreux sont les utilisateurs à se plaindre de l'apparition de fenêtres inutiles, et/ou avec des messages incompréhensibles.

En résumé, JWS peut être une option viable dans un environnement contrôlé, comme intranet dans une entreprise, mais n’est pas prêt pour le marché des consommateurs. Il pourrait être préférable d'utiliser des:

Java Web Start

Avantages

Disponible pour toutes les principales plates-formes de bureau

Distribution unique pour toutes les plates-formes compatibles JWS

Signature de code et sandboxing

Mises à jour de version et incrémentielles

Installation automatique du JRE et des paquetages optionnels

L'utilisation d'outils tiers est facultative

Désavantages

Connectivité Internet nécessaire si JWS, JRE, et/ou un paquetage optionnel n'est pas présents sur le système

Soutien pour le type MIME jnlp nécessaire à la fois sur le serveur Web et le navigateur

Capacités d'intégration de bureau Limitée

Ressources

Java Rich internet Applications Guide

Deploying Software with JNLP and Java™ Web Start

Java Web Start
(Glossaire Java Roedy Green)

Lopica - All Things Web Start
Outis
JavaFX Packager
Xito Application Manager
AutomaticJNLP Generator

Lorsqu'un programme Java est invoqué en utilisant l'une des méthodes décrites ci-dessus (fichiers bat, jar exécutable, ou Java Web Start/JNLP), le système d'exploitation exécute un lanceur Java à partir du JRE. La version Windows de l’environnent d’exécution Java (JRE) a deux lanceurs distincts: un pour une application en ligne de commande et un pour une application à interface graphique, nommés respectivement java.exe et javaw.exe.

Par conséquent, toutes les applications Java exécutées ont les mêmes icônes dans la barre de tâche/Alt-Tab et apparaissent dans le Gestionnaire des tâches de Windows en tant que, soitjava.exe, soit javaw.exe. Si vous avez deux ou plus applications Java en cours d'exécution, vous n’avez aucun moyen de faire la distinction entre plusieurs instances du lanceur Java standard dans le Gestionnaire des tâches.

En fait, ces lanceurs ne sont que de petits programmes natifs qui chargent la machine virtuelle Java à partir d'un DLL/bibliothèque partagée puis chargent votre programme à cette JVM en utilisant l'API d’invocation. Cet API fait partie de la Java Native Interface (JNI). Elle est donc standardisée et est très simple. Cela rend relativement facile l'écriture de votre propre lanceur avec un nom unique et une icône. Tout ce qu'il a à faire est de trouver un JRE approprié sur le système de l'utilisateur (sauf si vous compilez le JRE avec votre application), charger et initialiser la JVM, et exécuter votre application.

Si vous n’avez pas les bons outils, les compétences ou le temps de développer un lanceur personnalisé pour votre application Java, il y a quelques générateurs de lanceurs d'applications Java répertoriés dans la section Outils du cadre situé à droite. (C’est la section de cet article qui est mise à jour le plus souvent - il me semble que les développeurs Java adorent réinventer cette roue particulièrement). Certains d'entre eux offrent des fonctionnalités supplémentaires telles que l'écran de démarrage instantané, stdout et stderr, et ainsi de suite, le plus significatif étant le Wrapping.

Un wrapper Java est essentiellement un lanceur Java personnalisé qui est également une archive auto-extractible contenant toutes les classes de l'application, les jars et fichiers auxiliaires. Le wrapper décompresse ces fichiers au démarrage et les supprime à la fin. De cette façon, votre application est distribuée comme un seul exécutable.

Un wrapper consulte normalement le JRE au démarrage. Si le JRE n’est pas présent ou sa version ne correspond pas aux exigences de compatibilité de l'application, certains wrappers peuvent installer le JRE (si vous avez inclus le wrapper dans votre application) et/ou télécharger et installer la version requise du JRE.

Les wrappers plus sophistiqués peuvent également configurer l’association des fichiers et créer des raccourcis à la première exécution. Mais si vous avez besoin de quelque chose de plus complexe, comme les mises à jour automatiques ou un déploiement uniforme multiplateforme, regardez-les:

Lanceurs et Wrappers

Avantages

Vérification de la version du JRE

Téléchargement et paquetage du JRE

Votre propre lanceur avec nom et icône unique

Aucune formation pour les utilisateurs

Désavantages

Limité à la plateforme

Capacités d'intégration de bureau absentes ou très limitées

Ressources

JNI Specification and FAQ

Outils (Commercial)

Jar2Exe
NativeJ
JExePack
Jlaunch

Outils (Gratuits)

JavaFX Packager Nouveau
Packr Nouveau
conyay Nouveau
AppBundler Ant Task Nouveau
JSmooth
Launch4j
jstart32
exeJ
Java Launcher

Si tout ce dont vous avez besoin est d'installer une copie privée du JRE avec votre application et créer des raccourcis qui exécutent votre application sur ce JRE, vous pouvez utiliser n’importe quel générateur d'installeurs. Cependant, l'utilisation d'un outil compatible Java peut vous donner les avantages suivants:

  • La détection de l’installation ou téléchargement du JRE
  • Génération de lanceurs natifs
  • Fichiers des paramètres de la JVM modifiable par l’utilisateur
  • Redirection de stderr et stdout pour les sauvegardes des fichiers journaux et piles d'exception.
  • Enregistrement des applications Java en tant que services Windows et démons Unix

Cette catégorie est la plus diversifiée en termes de prix et de fonctionnalités. Les différences sont détaillées ci-dessous pour différents types d’exemples.

Les outils Windows-centric comme Advanced Installer for Java vous permettent de construire un paquetage d'installation MSI pour Windows.

Les outils multiplateformes comme install4j peuvent générer des installateurs natifs pour de diverses plateformes — Windows, Linux, Mac OS X, ainsi que les RPM et archives tar. Pour les applications JavaFX, vous pouvez utiliser JavaFX Packager, qui est capable de produire des paquetages MSI, DMG, RPM et DEB.

Il existe également des outils de création d’installeurs Java qui vous permettent de créer des installeurs multiplateformes. Ces installeurs sont essentiellement des jars exécutable avec une logique spécifique à la plateforme choisie au moment de l'exécution. InstallAnywhere est probablement l'outil de ce type le plus connu, mais son prix est au-delà de votre budget, pensez au logiciel libre comme par exemple JWrapper, même si il y a quelques restrictions. Il y a aussi l'ensemble des installateurs natifs et multiplateformes, ou encore le logiciel libre IzPack.

Finalement, il existe un outil qui les surpasse tous: InstallShield, qui peut créer à la fois des installations Windows desktop (MSI) et multiplateformes, ou encore pour server et mobile, et ce pour tout type d'application et pour une multitude de plates-formes. De plus, il supporte la recherche et l'intégration du JRE, les lanceurs natifs et ainsi de suite.

Cependant, pour les installations simples, InstallShield peut être assez disproportionné. Notez également qu'InstallAnywhere et InstallShield ciblent les gros éditeurs : les prix sont donc fixés en conséquence.

Toutes les solutions présentées ci-dessus ne changent pas le principe fondamental mentionné dans la première section de cet article : que vous fassiez un jar exécutable ou que vous créez un programme d'installation sophistiquée, votre programme Java est toujours déployé en tant que bytecode indépendant de la plate-forme. Dans les premiers jours de Java, la seule façon d'exécuter un programme Java sur un pc standard était d’interpréter le bytecode. Aujourd'hui, n’importe quelle implémentation décente de Java comprend un compilateur Just-In-Time (JIT) qui compile les méthodes fréquemment exécutées en code natif. Ainsi, il semble tout à fait naturel de faire un pas de plus et de compiler l'ensemble de l'application en code natif avant son déploiement. Ces outils existent et ils sont appelés:

Outils de création de programme d'installation

Avantages

Intégration de bureau

Peut être spécifique à la plateforme ou multiplateforme

Support de la régionalisation (localisation)

Flexibilité

Désavantages

Nécessite des outils tiers qui peuvent être trop chers et/ou complexes

Ressources
AppDeploy.com
Outils (Commercial):

Advanced Installer for Java
install4j
InstallAnywhere
InstallShield
JExpress
JWrapper

Outils (Gratuit):

JavaFX Packager Nouveau
IzPack
jelude (script NSIS )

Les compilateurs Ahead-Of-Time (AOT), sont aussi connus sous le nom de « compilateurs statiques » et «compilateurs de code natif ». Ce dernier terme est le plus utilisé, mais aussi, le moins bon d’un point de vue technique, parce que les compilateurs JIT produisent également du code natif.

Un compilateur Ahead-Of-Time (AOT) prend comme entrée vos fichiers jars et vos fichiers de classe puis produit un exécutable natif classique pour la plate-forme cible, tels qu’un fichier binaire EXE pour Windows ou ELF pour Linux. Tout comme n’importe quelle autre solution technique, il y a des avantages et des inconvénients.

Avantages

  • Performance. Un compilateur JIT fonctionne à l'exécution et partage les ressources du CPU et de la mémoire avec l'application qu'il compile avec potentiellement d'autres applications. Le compilateur AOT, lui, est utilisé sur le système cible en amont de l'exécution de l'application, donc sans contraintes de temps pour la compilation « au vol » du JIT. Par conséquent, il peut potentiellement utiliser plus de puissance et/ou de temps pour l’optimisation des ressources, et donc générer un meilleur code.

    Cet avantage est augmenté si votre application est déployée sur des systèmes intégrés ou des PC d'entrée de gamme, là où les compilateurs JIT n’ont tout simplement pas assez de ressources pour travailler.

  • Protection de la propriété intellectuelle. Le bytecode Java est très facile à décompiler - faites par exemple une recherche Google sur "download java decompiler " et vous obtiendrez votre code source en quelques minutes. Certes, vous pouvez masquer les noms des classes publiques et des méthodes qui ne sont pas accessibles via reflection ou JNI, mais un masquage exagéré peut rendre votre bytecode douteux sur les futures JVM, voire entraver la capacité du compilateur JIT à effectuer ses optimisations. Enfin, le cryptage de votre bytecode Java ne protège pas non plus votre propriété intellectuelle quel que soit l'algorithme de cryptage que vous utilisez.

    En revanche, le code natif produit par un compilateur Java AOT optimisé est aussi difficile à décompiler « reverse engineer » que si vous aviez écrit le programme original en C ++. Inutile de dire qu’il n'y a pas de perte de performance. Si vous êtes préoccupé par la protection de votre propriété intellectuelle, nous ne pouvons que vous conseiller d'examiner de plus près la compilation native.

  • Perception de l'utilisateur . Les applications clientes Java souffrent souvent du syndrome dit du cycle de préchauffage. Le démarrage d'une application Java implique l'interprétation du bytecode, le profilage et la compilation JIT. Donc les programmes Java ont tendance à démarrer beaucoup plus lentement que leurs homologues natifs. Par exemple le temps de réponse initial à une interaction avec un élément graphique complexe (GUI), comme une grille ou une arborescence, peut être assez long au départ, et s'améliore après qu'il ait été utilisé à plusieurs reprises. Voilà donc les deux raisons principales qui font que Java est encore perçu comme lent par de nombreux utilisateurs.

    Un exécutable natif, lui, s’exécute directement sur le matériel, sans la surcharge de travail que représente l’interprétation du bytecode, le profilage et la compilation. Il peut ainsi démarrer plus rapidement et manifeste immédiatement un meilleur temps de réponse aux interactions.

  • Déploiement natif. Même les outils d’installation compatible Java doivent générer un lanceur natif pour une meilleure intégration de bureau, et les lanceurs peuvent également avoir besoin de télécharger et d'installer le JRE.

    Les exécutables produits par un compilateur Java AOT ne dépendent pas de la JRE et peuvent être déployés à l'aide de n'importe quel outil de création de programme d’installation disponible pour une plate-forme en particulier. De plus, les compilateurs AOT peuvent intégrer avec des générateurs de programmes d’installation spécifiquement adaptés qui créent des installateurs compacts et professionnels.

Inconvénients

  • Applications dynamiques. Les classes que l'application charge dynamiquement lors de l'exécution peuvent être indisponibles au développeur de l'application. Ceux-ci peuvent être des plug-ins tiers, des proxies dynamiques et d'autres classes générées à l'exécution et ainsi de suite. Ainsi, le système d'exécution doit inclure un interpréteur de bytecode Java et/ou d'un compilateur JIT.

    D'ailleurs, dans la majorité des cas, seulement les classes qui sont chargées par l’un ou l’autre de ces systèmes ou par le chargeur de classe de l’application, peuvent être précompilées en code natif. Donc, les applications qui utilisent un chargeur de classes personnalisé peuvent n'être que partiellement précompilées, à moins que le compilateur AOT et le runtime ne soient au courant du comportement de ces chargeurs de classes spécifiques. Par exemple, des applications Eclipse RCP peuvent être entièrement compilées malgré tout, sauf  quelques centaines de classes de démarrage qui sont chargées par le chargeur de classe OSGi. Il est également possible de compiler des applications Web fonctionnant sur Apache Tomcat.

  • Optimisations spécifiques au matériel.

    Un compilateur JIT a un avantage potentiel sur les compilateurs AOT du fait qu'il est possible de sélectionner les modèles de génération de code selon le matériel sur lequel l'application s’exécute. Par exemple, il peut utiliser le dernier jeu d'instructions SSE pour accélérer les calculs en virgule flottante. Un compilateur AOT doit soit produire du code pour le plus petit dénominateur commun ou appliquer la création de versions aux méthodes les plus gourmandes en temps processeur, ce qui peut entraîner une augmentation de la taille du code.

Les idées fausses

Le bytecode Java avait été conçu au départ pour sa compacité, de sorte qu'il possède un niveau de complexité beaucoup plus élevé qu’un jeu d'instructions CPU typique et prend moins de place que le code machine équivalent pour un processeur d'usage général dans le monde réel, tel qu'Intel x86. Mais les fichiers de classes Java ne contiennent pas uniquement du code. La quantité d'informations symboliques dans les fichiers de classe Java a augmenté de façon spectaculaire au fil des années en raison du développement de nombreuses API et la structure de leurs paquetages. Actuellement, il n'y a guère de différences entre l’empreinte disque de la forme originale et celle de la forme compilée AOT d'une application. Par ailleurs, la taille du téléchargement peut être encore plus petite que celle du JRE.

Une autre idée fausse commune est que la compilation AOT tue la portabilité de Java. Ce n’est pas le cas, car le code source n’a pas besoin d’être modifié, donc vous pouvez toujours déployer votre application en bytecode sur une plate-forme pour laquelle vous n’avez pas de compilateur AOT. (Bien sûr cela éliminerait les bienfaits de la protection IP.)

Outils

Il y avait auparavant une demi-douzaine de compilateurs Java AOT sur le marché dans les années 2000, mais les deux seuls qui ont survécu sont Excelsior JET et GCJ (GNU Compiler for Java). Vous trouverez un comparatif de ces deux produits dans la section Bonus ci-dessous.

Mise à jour 07-Jul-2014: RoboVM est un nouveau projet libre intéressante qui vous permet de compiler du code Java en exécutables iOS natif. Cependant, il utilise la bibliothèque standard Android, pas de Java SE, donc vous obtenez seulement la portabilité entre iOS et Android.

Si vous êtes dans le domaine intégré, consultez Aonix PERC, qui vise J2ME CDC et a également un soutien limité pour J2SE 1.3.

Ceci met fin à la partie principale de l'article. Je la mets à jour régulièrement, donc si vous avez des commentaires ou connaissez des URL ressources/outils que j’aurais dû ajouter, merci de me les faire parvenir.

De plus n’hésitez pas à me contacter si vous avez besoin d'aide dans l'optimisation, protection et/ou le déploiement de vos applications Java.

Compilateur AOT

Avantages

Augmentation des performances d'exécution

Protection IP

Meilleure perception de l'utilisateur

Déploiement natif

Désavantages

Applicabilité limitée

Les idées fausses

Augmentation de l'empreinte de disque

Perte de portabilité

Ressources

Improving Swing Performance: JIT vs AOT Compilation

Cracking Java byte-code encryption

Tools
Excelsior JET
GCJ
RoboVM (iOS) Nouveau
Aonix PERC
Avis de non-responsabilité: Je travaille pour la compagnie qui fabrique Excelsior JET, alors veuillez sauter cette section si vous croyez qu'elle constitue une publicité éhontée.

Plateformes cibles

Depuis juillet 2014, la page officielle GCJ Status page énumère 15 objectifs pris en charge, à partir de "bare metal" ARM et XScale aux mainframes IBM s390x. Cependant certain de ces objectifs, notamment Windows, ne sont pas entièrement pris en charge.

Excelsior JET prend en charge Windows et Linux sur 32 et 64 bits x86. La version 32 bits de Windows est sur le marché depuis les années 2000, celle de Linux, a rejoint le marché en 2004. Maintenant les deux ont atteint une certaine maturité. Les versions 64 bits, d'abord publiées en 2013, sont en train de reprendre du terrain.

Mise à jour 23-jul-2014: Depuis la version 10, Excelsior JET est également disponible pour OS X, alors maintenant il prend en charge tous les principaux systèmes d'exploitation.

Conformité aux normes

GCJ n'a pas passé la suite de test officielle d’Oracle Java Compatibility Kit (JCK) et est assez loin de même tenter de le faire. La raison principale est que la bibliothèque d'exécution GCJ, libgcj, est une implémentation libre clean-room des classes de l’API du noyau Java, et de ce fait était loin derrière le développement Sun avant même la prise de contrôle d'Oracle. Maintenant GCJ ne peut compiler que des applications graphiques créées à l'aide du toolkits graphique tiers AWT-indépendant, comme SWT.

libgcj se fusionne lentement avec GNU Classpath. Les résultats non officiels des tests de compatibilité pour GNU Classpath affirment qu'il comprend la plupart, mais pas toutes les fonctionnalités JDK 1.4 de l'API à partir de septembre 2007 (la dernière fois que les tests ont été effectués.) Notez cependant que les données utilisées pour soutenir cette revendication ne sont pas produites en exécutant le JCK, alors ils peuvent seulement confirmer la disponibilité, et non la compatibilité des API respectives.

Excelsior est un Titulaire de Licence Autorisé Java, et son produit utilise les implémentations de la licence Oracle de l'API Java SE. Excelsior JET a passé le JCK et est certifié Java SE 8 Compatible sur un bon nombre de plates-formes Windows et Linux.

Chargement de classe dynamique

Les deux produits supportent le chargement dynamique de classe. Le runtime GCJ exécute dynamiquement les classes chargées dynamiquement sur un interpréteur, alors que le runtime Excelsior JET dispose d'un compilateur JIT.

Facilités de déploiement

GCJ est seulement un compilateur; vous êtes responsable de choisir un outil de déploiement tiers et de configuration pour l'emballage des exécutables GCJ produits.

Excelsior JET comprend un ensemble d'outils qui vous permet de créer des installateurs Windows et Linux compacts ou s’intègre facilement avec des générateurs de configuration tiers. Vous pouvez également compiler vos applications Java dans les services Windows.

Prix

GCJ et libgcj sont des logiciels libres (GPL) et peuvent donc être téléchargés librement, modifiés et distribués. Notez qu’une exception 'libgcc' s’applique à libgcj, donc son utilisation n'entraîne pas le fait que votre programme tombe sous la licence GPL.

Le prix de la licence d'utilisation JET Excelsior s'établit à partir de 1,500 $ par développeur, avec des rabais substantiels offerts aux entreprises qui débutent ainsi qu’aux très petites entreprises.

Les auteurs de programmes Java non commerciaux librement téléchargeables peuvent demander une licence libre.

Le déploiement de postes de travail à usage général et de serveurs est libre de droits, mais des frais d'exécution s’appliquent si vous déployez votre application à des systèmes intégrés ou si vous l'empaquetez avec des dispositifs qui fournissent une fonctionnalité dédiée.

M. Andrew Fedoniouk a soumis à mon attention à son projet passé appelé J-SMILE qui vise à permettre la création d'applications Java GUI qui fonctionnerait sans JRE. C’était essentiellement une combinaison de la Waba VM et une petite API graphique, qui pourrait être empaquetée avec vos fichiers de classe d'application dans un exécutable d’au plus un mégaoctet.

Si vous connaissez d'autres tentatives intéressantes pour se débarrasser de la JRE, merci de me les faire parvenir.

Est-ce que cet article vous a été utile? Si oui, nous avons plus de contenu pour vous!

Découvrez d'autres articles écrits par les membres du personnel Excelsior: