Oui mais Java est multiplateforme

A partir du moment ou il n y a pas d appels a du jni.. Le cote multiplatforme est dans de nombreux cas qu une illusion :/

Un truc récenent et intéressant : http://blog.developpez.com/index.php?blog=51&p=1389&more=1&c=1&tb=1&pb=1#more1389

Intéressant lien, lag-it.

Sauf que notons tout de même qu´ici on est plus du ressort de combats à l´interne entre Javas, et non pas entre langages...
Mais je pense que ça peut déjà donner une ptite idée que le code non-interprété peut tout de même très bien tenir la route, ce qui n´en fait donc pas automatiquement un langage abhorrable de par sa lenteur...

"> Oui mais Java est multiplateforme"
Tout dépend de ce qui est entendu par multiplateforme...

Du moment qu´il n´y a pas appel à des capacités intrinsèques de la plateforme cible, et qu´il y ait moyen de faire rouler le code sur cette machine (que ce soit par un compilateur supportant l´OS ou une machine virtuelle par exemple) tout langage est théoriquement multiplateforme.

Donc ici je rejoins Bigloo et kufa...
La multiplateformité n´est pas un avantage décisif pour Java, n´importe quel langage, avec les ressources en place et le code adéquat, feront de même.

Kelios
---------

Plus que l´aspect multi-plateformes, c´est le fait qu´on puisse compiler/générer un jar sur une machine quelconque et le faire fonctionner sur n´importe quel autre platerforme sans devoir tout recompiler.
Essayez donc de faire pareil avec du C++, par exemple.

lag-it : très bon article, en effet, je comptais en parler mais tu m´as devancé. Ça tort le coup à cette vieille idée reçue de lenteur de la JVM, c´est pas du luxe car elle n´a plus du tout lieu d´être.

Feufeu: une application simple realisee en java sera un jar qui tourne pratiquement partout, certes. Rajoute des appels a des jni, et hop, fini, ton jar ne fonctionne plus du tout partout. Ensuite zut, il te manque une lib, ca tourne pas. Ha ensuite jdk5.0 a de gros problemes avec les procs HT, certaines JVM sont supers bugges, surtout lorsqu on fait de l embedded (hmm vive la hotspot..)
Pour du dev sur portable, du code c++ bien fait est bcp plus "portable" que du code java.

Ensuite la plupart des tests c++ vs java sont bidons, pleins de params jouent sur le cote java et c++ et ne sont pas pris en compte (prends un gc dans les dents pendant un test, ca plombe bcp..). Et puis utiliser gcc/g++ pour faire des tests, c´est pas tres serieux..

/kUfa

JNI, évidemment si on prend des exemples pareils... Et puis la façon dont tu en parles laisse supposer que sans JNI & Co., on ne fait pas de Java "complexe" (par opposition à ton ´application simple´).

Pour les lib, si elles ne sont pas fournies avec la JRE, rien n´empêche de le mettre dans l´installeur, c´est un faux problème, ça.

Quant aux bugs de la JVM et ou les soucis d´hyperthreading, je ne vois pas le rapport avec la portabilité.

Dernière remarque : l´article pointé par lag-it ne fait aucune comparaison C++/Java, il se contente de comparer les performances des différentes JVM et ce qu´on peut obtenir en compilant du Java en code natif avec les outils les plus connus. Quant à des tests qui font effectivement cela, je n´y prête aucune attention : ils ne prennent jamais en compte un quelconque contexte et se contentent de faire des benchmarks sans grande valeur...

Après, dans l´absolu, je ne sais pas si Java ou C++ est plus "portable" dans du développement embarqué, je n´en ai jamais fait. Je serais donc ravi d´avoir un avis argumenté à ce sujet

Y a le D !
Le D est langage compilé, un tout petit peu moins rapide que le C++ mais c´est quasiment rien. Il possède toutes les caractéristiques du C++ (poo, pointeurs, mémoires, ...) mais il a d´autres outils comme le Garbage collector, etc... En plus, le D est multiplateforme !

Voici un jeu programmé en D :
http://www.asahi-net.or.jjp/~cs8k-cyu/windows/tt_e.html

Sans oublier le Goto++

feufeu: de tres nombreuses libs ont des acces jni, normal. Je ne dit pas que l´on ne peut pas faire de grosse applications sans des appels jni, mais je te garanti que le fait de dependre de libs specifique enleve enormement au cote multiplatforme..

Pour les lib, si elles ne sont pas fournies avec la JRE, rien n´empêche de le mettre dans l´installeur, c´est un faux problème, ça.

Non pas du tout. Exemple tout con: application sur pc qui utilise gl4java (=>jni), comment le faire tourner sur mon amiga, a moins de faire le port de gl4java..

Quant aux bugs de la JVM et ou les soucis d´hyperthreading, je ne vois pas le rapport avec la portabilité.

Ben c´est simple. Par exemple, pour mon dernier jeu j ai programme un petit outil qui ne fonctionne pas avec l´HT (a cause de bugs dans la jvm), sauf que moi j´ai develope sans HT. Donc a cause de bug de la jvm, je devrais modifier mon code assez profondement pour pouvoir le rendre multiplatforme. Autre exemple, certain tel nokia pondent n´importe quoi si tu multiplie deux float tres petit (au lieu de rendre 0), donc super la portabilite. Je ne dis pas que c´est propre au java, loin de la, mais je trouve le terme "multiplatforme" assez.. marrant..

Sinon pour l´article, je ne l´avais que survole, mon erreur, et je suis tout a fait d´accord que les tests c++ vs java sont totalement inutiles.

Après, dans l´absolu, je ne sais pas si Java ou C++ est plus "portable" dans du développement embarqué, je n´en ai jamais fait. Je serais donc ravi d´avoir un avis argumenté à ce sujet

Pour des jeux sur tel portable, c´est la merde pour les deux jvm/jsrs buggees, brew/mophun/symbian pas mieux..

La différence entre Java et C++ au niveau de la portabilité, c´est que pour Java, il faut un interpréteur pour chaque machine, et le C++ il faut un compilateur pour chaque machine.

kuja : merci pour ces précisions, je comprends beaucoup mieux où tu voulais en venir, et je ne peux qu´adhérer (et le problème des float m´a fait sourire, c´est un grand classique mais c´est particulièrement chiant)

D´après ta carte de visite et les exemples que tu prends, j´ai l´impression que ces problèmes sont l´apanage des librairies graphiques. La seule librairie graphique à laquelle je me suis frotée est SWT qui, effectivement, utilise JNI et nécessite donc des librairies spécifiques à la plateforme.

Pour ma part, je suis beaucoup plus orienté bureautique, informatique de gestion. Par conséquent, les librairies que j´utilise fréquemment n´utilise pas JNI : les accès aux BDD, les librairies XML comme JDOM ou Xerces, les librairies comme logging, itext (pour convertir en PDF), blowfish (pour utiliser l´encryption du même nom)... Dans mon cas, je n´ai pas qu´à coller le jar dans l´installeur et ça passe tout seul.

D´où la divergence d´opinion, je pense.

En même temps, je suis conscient que le côté multi-plateforme est trompeur. Je ne compte les exemples d´application Java qui sont développées sous Window ou Linux, mais qui finissent par tourner sur Mac : le résultat est effrayant, notamment au niveau des interfaces graphiques. Ce n´est pas pour rien qu´Apple a fourni une documentation technique très poussée expliquant comment créer une interface graphique potable sur leur système ^^

feufeu: je pense que nous avons la meme vision de la chose, je voulais juste donner quelques exemples sur le cote utopique du terme "multi-platforme" (en java ou c++, ou n importe quel language)

"Plus que l´aspect multi-plateformes, c´est le fait qu´on puisse compiler/générer un jar sur une machine quelconque et le faire fonctionner sur n´importe quel autre platerforme sans devoir tout recompiler.
Essayez donc de faire pareil avec du C++, par exemple." Voilà c´est ça que je voulais dire.

<troll>C´est possible avec du C#...</troll>

Via Mono ?

Via mono ou autre. Il y a des outils de MS qui existe pour ça, ou en tout cas ils en ont fait des démonstrations. Mais je ne pense pas que ça soit déjà au point.

Par contre, il existe des interpréteurs de C sur toutes les plateformes. Donc, à partir de ce moment là, on en arrive au même point qu´avec le java : ce n´est plus qu´un langage interprété qui a accès à des bibliothèque plus au moins portables.

le truc fort avec C# c´est qu´il peut facilement integrer un module du style, si tel lib n´est pas disponible, la telecharger, et l´executer.
en effet, en C# il est prevu de compiler une chaine de caractere contenant du code et de l´executé.
en soit, ce n´est pas extrement novateur, mais c´est amusant...
je devrais me mettre a C# un jour...

Autant te mettre à Python, y´a carémment un type pour le code.

<simple sécurité>
Bien sûr c´était de l´humour, haha.
</simple sécurité>

C´est une fonctionnalité qui existait déjà en VB6 : avec le controle de script, on pouvait exécuter des chaines qui pouvait manipuler les objets.

Mais je ne vois pas le rapport avec la mise à jour automatique : ça peut très bien se faire sans cette fonctionnalité.

je n´avais pas parlé de mise a jour...
deplus j´avais bien dis, "ce n´est pas extrement novateur", mais c´est marrant quand meme!