Je pose cette question parce que maintenant le développeur doit compiler son code sur différents systèmes d'exploitation tels que Windows, Linux ou Mac OS afin de créer le produit livrable final. Il a l'air plus grand sur le dessus des développeurs.
3 Réponses :
Oui bien sûr, il est toujours indépendant de la plate-forme.
Java Bytecode ne change pas entre Windows, Linux ou Mac OS.
Vous pouvez prendre les fichiers de classe compilés sous Windows ou un fichier JAR avec des classes à l'intérieur, et copiez-les sur une machine Linux ou Mac OS, et ils fonctionneront, à condition que la version principale de la plate-forme soit la même ou la version ultérieure que celui de celui où ils ont été compilés à l'origine.
Donc, s'ils ont été compilés avec un compilateur Java 9 ciblant un runtime Java 9, la plate-forme les exécutant devra être Java 9 ou ultérieure. Sinon, vous obtiendrez un non supportéClassversionError .
Java est indépendant de la plate-forme mais JAVA Runtime Environment (JRE) n'est pas.
Donc, si le développeur veut fournir un produit pour diverses plateformes sans installer JRE dans l'environnement de l'utilisateur, Le produit doit contenir différentes JRE pour chaque plate-forme.
+) La compilation n'a pas d'importance, cela doit être fait juste une fois.
Vous semblez avoir mal compris le Emballage de l'application contenue capacité de Java 9 qui semble défini pour remplacer Java Web Start en tant qu'outil de déploiement pour les applications de bureau.
JWS a utilisé un pot ordinaire comme étant livrable mais requis qu'un environnement d'exécution Java sur la machine utilisateur est déjà installé. D'autre part, l'outil d'emballage enveloppera ce bocal dans un exécutable approprié pour Windows (A .exe) ou UNIX (A .SO), etc., il exigerait que l'exécutable indigène ait les parties du code JRE codé Pour chaque système (les pots sont indépendants de la plate-forme mais que JRES doit être faite pour chaque système d'exploitation).
Si vous livrez un bocal exécutable à l'utilisateur (et que vous les informez, ils ont besoin du plug-in Java installé, de l'exécuter), ce pot sera toujours compatible pour tous les OS sur lesquels Java est pris en charge.
Eh bien, vous avez raison que l'emballage de l'application autonome nous donne définitivement une belle solution pour se débarrasser de Bulky Jre que nous téléchargions et que nous installions jusqu'à Java 8. Mais j'ai mentionné ici cela comme une surcharge pour les développeurs, car tout le monde n'a pas Linux et Mac OS sur leurs machines. Donc, je pense qu'il serait préférable d'avoir une sorte d'image de l'outil / de la boîte virtuelle / de la boîte virtuelle qui pourrait contenir tout système d'exploitation et exécuter ces outils d'emballage pour faciliter les travaux de développeurs.
"Eh bien, vous avez raison que l'emballage d'applications autonome nous donne définitivement une bonne solution pour se débarrasser de Bulky Jre que nous téléchargions et installions jusqu'à Java 8." Vous lisez trop dans ce que je suis a écrit. Je n'ai aucun avis sur si c'est "gentil". C'est juste la façon dont Oracle a décidé. "Mais j'ai mentionné ici cela comme une surcharge pour les développeurs, car tout le monde n'a pas de linux et de Mac OS sur leurs machines" pourquoi devraient-ils avoir à être? ..
.. »Donc, je pense qu'il serait préférable d'avoir une sorte d'image d'outil / d'image / de boîte virtuelle qui pourrait contenir tout système d'exploitation et exécuter ces outils d'emballage pour faciliter les travaux de développeurs." pense tout ce que vous voulez. Mais il s'agit d'un site de questions / réponses, pas de .. Forum de plaidoyer et d'opinion. Votre question a été répondu.
Quel "produit livrable final" parlez-vous?
"Développeur a besoin de compiler son code sur différents OS" qui vous a dit cela?
Vous avez raison, j'aurais dû utiliser emballé au lieu de compiler.