Comment un jeu Java de bureau peut-il être distribué sans dépendance d'exécution Java?

Est-il possible de transformer une application Java en un package autonome qui s'exécute "prêt à l'emploi"? L'utilisateur final ne doit pas être obligé d'installer de Java JRE, ni le programme d'installation doit contenir un JRE et l'installer pour l'utilisateur.

La distribution finale devrait contenir un exécutable natif (si tout va bien un pour chacun de Windows, Mac et Linux) avec les fichiers de données réguliers et tous les fichiers JAR supplémentaires si nécessaire. Je ne recherche pas spécifiquement une solution "un fichier" - j'aimerais en fait que les fichiers de données ne soient pas obscurcis.

Comment cela peut-il être fait?

java distribution

— leokhorn
source

Réponses:

Le point principal est que l'utilisateur final ne devrait pas être tenu d'installer un Java JRE, ni que le programme d'installation doit contenir un JRE et l'installer pour l'utilisateur

Vous pouvez utiliser Java source / bytecode pour compiler des compilateurs de code. Il existe Excelsior JET pour Windows et Linux (nécessite une licence) et GNU Compiler pour Java qui est ancien.

S'il est correct de contenir Java avec votre jeu sans l'installer, vous pouvez probablement empaqueter Java Runtime avec votre jeu et utiliser un script de démarrage pour définir JAVA_HOMEvotre emplacement JRT avant de lancer le jeu.

EDIT: (réponse au commentaire) En utilisant la deuxième option, vous aurez toujours besoin de différentes versions pour différentes plates-formes en utilisant le runtime Java approprié pour cette plate-forme.

EDIT2: Voir également le récent commentaire de Dmitry.

— Eren Güven
source

Si votre jeu n'est pas commercial, vous pouvez obtenir une licence Excelsior JET gratuite .

— Dmitry Leskov

La deuxième option semble bonne, mais si j'emballe mon Windows JRE, est-ce une plateforme croisée? De même avec Excelsior, aurais-je besoin d'exécuter de tels compilateurs sur les trois OS différents?

— leokhorn

Vous devrez regrouper ces plates-formes JRE avec chaque version, mais il restera essentiellement multiplateformes.

— Derek

@leokhorn À un moment donné, il doit y avoir du code natif. Soit vous devez compiler en code natif, soit vous devez exécuter sur une machine virtuelle native. Il n'y a pas de plan C.

— Adrian

GCJ est maintenant officiellement mort , tandis que l'Excelsior JET Standard Edition est également devenu gratuit pour un usage commercial , bien que si votre seul souci est la facilité de distribution, il existe de nombreuses alternatives

— Dmitry Leskov

Pour Mac, consultez la documentation Oracle pour empaqueter une application Java pour Mac . Ils ont configuré Java 7 pour que vous puissiez regrouper le runtime dans un ensemble d'applications contenant vos fichiers jar (.app est un dossier vraiment exécutable), qui est requis pour la distribution sur le Mac App Store. Fondamentalement, le bundle .app fait essentiellement la même chose que ce que suggère la réponse JAVA_HOME d'Eren, mais il est conditionné comme une application Mac "native".

Pour une distribution sans le Mac App Store, vous pouvez vous passer de ne pas signer l'application, en disant à vos utilisateurs Mountain Lion qu'ils peuvent contourner Gatekeeper en cliquant avec le bouton droit (ou ctrl + clic) sur votre application et en cliquant sur "Ouvrir" quand ils ouvrez d'abord l'application. Cela les avertira toujours que l'application n'est pas signée, mais cela leur permettra quand même de l'ouvrir, puis leur permettra de double-cliquer sur l'application pour les ouvertures suivantes.

(note latérale: vous pouvez également vous en tirer avec le marquage de scripts shell de type Linux comme exécutable, puis construire un bundle .app autour de cela. NetBeans le fait sur Mac et Linux, mais sans JRE / JDK fourni)

— Le crabe
source