Java est-il (encore) le langage multiplateforme de choix? [fermé]

Quand j'ai commencé à utiliser Java dans les années 90, tout était « Écrivez une fois, exécutez n'importe où! » Dès le premier jour. C'était probablement vrai à l'époque et je faisais aussi partie de la chorale.

Je ne sais plus quoi penser de cela, compte tenu de toutes les autres langues utilisant des runtimes multi-plateformes (python, flash, perl, html, php ...). Mais je vois toujours beaucoup d'arguments qui disent que vous devriez utiliser Java car il est censé être meilleur pour le développement multiplateforme.

Alors, est-ce toujours vrai aujourd'hui? Java est-il toujours le langage de choix pour le développement multiplateforme?

• Veuillez être précis en mettant l'accent sur les aspects multiplateformes.
• Je ne demande pas de comparaisons générales des fonctionnalités linguistiques.

Mise à jour: excellentes réponses à ce jour! La plupart des réponses semblent favoriser Java ou le Web. Avez-vous des commentaires de la foule de script?

les langages de style de script tels que python facilitent également le développement multiplateforme. Maintenant, que vous aimiez Python (ou d'autres langages de ce type) dépend de vous, et nous n'avons probablement pas besoin d'ouvrir ce débat ici.

Java essaie de vous forcer à écrire du code qui s'exécutera de manière portable, tandis que python vous permet d'écrire du code portable. Le langage python proprement dit s'exécutera de manière portable, mais les bibliothèques externes peuvent ou non. De plus, python donnera librement accès à des services spécifiques à la plate-forme.

Java y a-t-il un avantage? Je pense que dans les deux cas, vous pouvez écrire le code portable avec la même facilité. Autrement dit, vous pouvez écrire du code et cela fonctionnera généralement sur différentes plates-formes. Mais vous ne pouvez pas vous contenter d'écrire du code et de supposer qu'il fonctionnera partout. J'ai travaillé sur un projet python qui a produit une version pour Windows, Linux et Mac et nous avons rencontré très peu de problèmes multiplates-formes. (Le seul dont je me souvienne était dû à un bogue dans la bibliothèque que nous utilisions pygame, ce qui a causé des problèmes de dessin sur Linux. Cela a été corrigé en mettant à niveau la version de pygame que nous avons utilisée)

Un autre problème est le déploiement. Si vous souhaitez distribuer des programmes autonomes qui exécutent votre code, vous devrez produire différentes versions pour différentes plates-formes. Pour Java, vous pouvez distribuer une version et supposer que l'utilisateur a installé Java ou peut l'installer. Dans ce cas, Java gagne probablement dans la simplicité du département de déploiement.

En fin de compte, je pense que cela dépend de la langue avec laquelle vous aimez travailler et du type de déploiement que vous devez effectuer.

Bien que Java ne soit pas le ou le seul outil multiplateforme viable , il a quelques points forts:

• C'est extrêmement rapide.
• C'est extrêmement robuste.
• Il est extrêmement portable (par exemple, le bytecode compilé il y a 10 ans dans Windows 95 fonctionne bien sous OS X aujourd'hui).

et quelques faiblesses:

• Les bibliothèques GUI de base (Swing ...) montrent leur âge (les ajouts tiers aident ici).
• La langue elle-même pourrait être moins verbeuse (par exemple, les exceptions vérifiées ...).
• Le temps de démarrage pourrait être plus rapide (bien qu'il s'améliore tout le temps).

Quand on parle spécifiquement de Java la plateforme , il y a un point de plus:

• Il existe plusieurs langages qui s'exécutent sur la JVM et interagissent avec Java.

C'est aussi vrai aujourd'hui qu'il l'était à l'époque - c'est-à-dire pas entièrement. Java est à écrire une fois, à tester et à déboguer partout. Bien sûr, c'est beaucoup moins de travail qu'un port complètement nouveau, mais c'est généralement plus de travail que le battage médiatique initial nous l'avait fait croire.

Notre produit possède un serveur Java qui fonctionnera sur Windows ou Linux mais nous avons vu des problèmes spécifiques au système d'exploitation et nous nous assurons que des serveurs Linux et Windows sont disponibles pour le support / test si nécessaire. Les interfaces utilisateur Java ont tendance à avoir plus de problèmes que les serveurs (bien que beaucoup soient cosmétiques et peuvent donc potentiellement être ignorés en fonction de l'application).

Bien qu'il ne soit pas strictement un langage pour moi, le Web est la plate-forme multiplateforme de choix. Un frontal HTML / JavaScript signifie que votre application s'exécutera sur à peu près n'importe quelle plate-forme client et dans la plupart des cas, c'était le véritable objectif - ne pas avoir à vous soucier s'il s'agissait d'un Mac ou d'un PC, quelle version du système d'exploitation, etc.

Bien sûr, vous dicterez généralement la plate-forme serveur, mais lorsque les gens deviennent beaucoup plus flexibles, en particulier de nos jours, lorsque la plupart des entreprises prennent déjà en charge un mélange de serveurs Windows et Linux.

Personnellement, je dirais que Java est toujours le langage multiplateforme de choix et qu'il y restera probablement un certain temps (aux côtés des applications Web). J'ai écrit un peu plus sur le sujet dans cet article sur Java en tant que plate-forme de choix , mais sur le front multiplateforme en particulier:

• Tant que vous faites attention à vos dépendances (par exemple en évitant les bibliothèques qui utilisent JNI pour interfacer avec du code natif), Java peut être écrit sans modification sur toutes les principales plates-formes JVM

• Beacuse Java est généralement distribué en tant que bytecode indépendant de la machine, vous pouvez l'exécuter sans recompilation sur n'importe quelle JVM (car la JVM locale elle-même gère la compilation JIT en code natif). Par exemple, j'ai réussi à faire fonctionner une application graphique complexe et raisonnable pour la première fois sur un Mac après avoir développé sous Windows - avec le même fichier jar . Comparez cela à la plupart des autres langages multiplateformes, qui nécessitent généralement différentes bibliothèques ou une recompilation pour une plate-forme différente.

• Un grand nombre des bibliothèques de base dont vous avez besoin (interface graphique, réseau, IO, etc.) font partie du runtime standard et sont écrites de manière multiplateforme. Vous n'avez donc pas besoin d'aller chercher et de tester les bibliothèques multiplateformes, vous avez la garantie que presque tout ce dont vous avez besoin est déjà là dans l'environnement d'exécution.

Je pense que vous avez ces choix:

1) utilisez soit un

• compilé ou
• langage interprété.

2) Comment allez-vous emballer et livrer votre code?

• Un "front-end", un binaire / script?
• Un "front-end", plusieurs binaires / scripts?
• Plusieurs "front-end", plusieurs binaires / scripts?

Ces choix affectent les performances, la visibilité du code source et la distribution.

Cela vous dérange de donner votre code source? Les langues compilées pourraient être pour vous. Les langues compilées semblent mieux fonctionner dans les micro-benchmarks que les langues interprétées (même JITed). De plus, si vous dépendez d'un environnement d'exécution comme Java, Python, Ruby, etc., votre code peut être plus difficile à distribuer.

J'ai constaté que les applications de bureau multiplateformes les plus populaires optent pour "Un frontal, plusieurs binaires" en utilisant C / C ++ et une bibliothèque de widgets multiplateforme, par exemple Audacity, Blender, Firefox, Google Earth, OpenOffice, Skype, Songbird, Stellarium, VLC.

Je dirai non. python et ruby ​​sont beaucoup utilisés, tout comme le javascript, côté client et côté serveur. J'utilise personnellement .NET et je n'ai aucun problème à le faire fonctionner sur mac et linux (lors du développement sur Windows)

-edit- j'entends que LLVM devient populaire mais est encore extrêmement petit. Cela vous permettra d'utiliser C ++ multiplateforme dans un seul binaire. Apparemment, il sera exécuté sur le navigateur, mais je n'ai pas vu d'exemple où il vous permet de modifier le dom ou d'appeler javascript.

Si vous intégrez des plates-formes mobiles, vous devrez également au moins inclure la recompilation. Par exemple, android, j2me.