Comment les applications Java sont-elles déployées dans le "monde réel"?
En tant que novice dans le monde de la programmation Java, cette question m'a toujours embourbé. J'ai d'abord cru que tous les fichiers Java étaient compactés en applets puis exécutés, mais j'ai vite réalisé que ce n'était pas toujours le cas. Quelqu'un pourrait-il m'expliquer comment nous entrelacons réellement nos applications Java dans un véritable produit de la vie quotidienne?
TL; DR: Comment implémentons-nous notre code pour une utilisation pratique?
4 answers
Cela dépend de l'application. Il existe de nombreuses options en fonction de la façon dont vous souhaitez que vos utilisateurs utilisent votre application. Habituellement, il est emballé comme un pot ou un pot spécialisé (guerre, oreille).
En théorie, vous pouvez compresser la structure de répertoire raw avec vos fichiers .class et fournir un script shell/instructions qui exécutent la commande java pour l'utilisateur. Je ne recommande pas cela car ce n'est pas professionnel et vous oblige à maintenir un script shell pour chaque système d'exploitation que vous souhaitez pouvoir exécuter le programme sur.
Les fichiers Jar sont utilisés pour empaqueter les bibliothèques, mais vous pouvez également y avoir un fichier manifeste qui dit: "Quand quelqu'un double-clique/exécute cela, exécutez cette classe". Cette classe peut démarrer une interface graphique ou être une tâche sans tête qui répond aux paramètres, etc.
, Vous pouvez avoir applets, comme vous l'avez dit. Ces programmes sont exécutés dans le navigateur de l'utilisateur.
Vous pouvez avoir un war file, qui est un moyen d'empaqueter une application Web. Vous donnez ce à un serveur web et il sait comment le déployer pour que vous puissiez visiter les pages web. Un exemple de serveur web/conteneur tomcat ou jetée.
, Vous pouvez avoir un oreille fichier, qui peut contenir d'autres fichiers war à l'intérieur. Ceci est utilisé pour les applications qui ont besoin d'autres parties de la fonctionnalité javaee (ejbs, files d'attente jms, etc.). Un exemple de serveur d'applications est jboss ou glassfish.
Il y a aussi java web start des apps. Ce sont des applications que vous pouvez exécuter en visitant une page Web, mais elles sont téléchargées sur votre ordinateur et s'exécutent sur l'ordinateur de l'utilisateur (au lieu du backend du serveur, comme dans une guerre/oreille).
Il y a aussi javafx. Je ne sais rien à propos de cela. En parcourant la FAQ, il semble être la réponse de Java à Flex d'Adobe. Vous configurez les composants de l'interface utilisateur avec une configuration XML. Je ne sais pas quel format les applications JavaFX utilisent, mais il dit: "Déployer sur le ordinateur de bureau ou dans le navigateur".
Comme Sotirios Delimanolis mentionné dans un commentaire ci-dessous, vous pouvez construire ces fichiers avec des systèmes de construction comme Ant ou Maven. Vous pouvez également les construire" à la main " avec les outils fournis avec le sdk java/javaee. Par exemple, vous devriez avoir une commande jar dans votre path si vous avez installé le sdk. Voici quelques détails de ces systèmes de construction:
- Maven
- Haut niveau (vous lui dites quoi construire, pas comment le construire)
- Beaucoup plus qu'un simple système de construction. Il a également la gestion des dépendances,etc.
- Opinionated (il utilise la convention sur la configuration, chaque fichier de configuration génère 1 artefact, etc.)
- Ant
- Bas niveau (vous lui dites comment construire des choses)
- Flexible
- Les fichiers de configuration peuvent faire ce que vous voulez, construire autant d'artefacts que vous le souhaitez
- Facile à apprendre
- Outils du SDK
- Toujours à jour. PAR EXEMPLE: Très rarement, maven / ant peut ne pas être en mesure de définir une option de configuration
- Commandes difficiles à mémoriser
- Niveau très bas
- En soi, non reproductible (PAR EXEMPLE: à moins que vous ne construisiez un script, vous devrez taper vous-même la commande jar à chaque fois)
- Les Applets n'ont jamais vraiment pris et sont très rarement utilisées de nos jours.
- Des applications simples peuvent être déployées en tant que fichiers "exécutables" JAR , qui sont essentiellement des archives ZIP avec des métadonnées supplémentaires qui indiquent à la JVM quelle classe contient la méthode principale à exécuter. Ils peuvent être exécutés sur la ligne de commande en utilisant l'option-jar, ou dans la plupart des environnements de bureau en double-cliquant (cela nécessite également l'installation d'une JVM).
- Les applications de bureau peuvent être déployées via Java Web Start ou des installateurs comme IzPack ou Install4J , mais les applications de bureau Java ne sont pas très courantes non plus.
- De nos jours, la plupart des logiciels Java ne fonctionnent que sur des serveurs (serveurs Web ou serveurs d'applications). Ils sont généralement déployés sous forme de fichiers WAR ou EAR , qui sont également des archives ZIP contenant des classes et d'autres ressources. Ces applications s'exécutent ensuite à l'intérieur d'un composant serveur suivant le Servlet ou EJB norme.
Créer un jar exécutable, une guerre qui est tombé dans un serveur web ou une bibliothèque qui est utilisé par un autre projet qui est l'un des deux précédents.
Si l'application est censée s'exécuter sur un client, elle est empaquetée en tant que JAR exécutable, puis empaquetée en tant que Bundle d'application (Mac), peut-être encapsulée dans un exe (Windows) ou associée à un script exécutable qui lancera le JAR et définira tous les arguments de machine virtuelle requis.
S'il fait partie d'une application Web, il sera empaqueté en tant que WAR ou EAR et placé à l'emplacement approprié sur le serveur Web.
S'il s'agit simplement d'une bibliothèque, elle est généralement emballée sous forme de pot (non exécutable) et distribué en tant que tel pour l'intégration dans des projets plus importants.
Applets puis couru, mais je me suis vite rendu compte que ce n'était pas toujours le cas
En fait, les applets sont rares de nos jours et leur utilisation est déconseillée.