>Pour la portabilité.. je me répète.. ça fait 5 ans, j'ai jamais eu de problèmes... si >une fois, l'appli marchait sous Windows mais on a eu une exception sous Linux.. parce que la librairie X était pas installé et on a eu un problème sur les couleurs (génération de PDF).
On ne peut meme pas dire que ca soit un probleme de portabilite vu que ton code aurait marche sur un linux installe avec un serveur X. C'est un classique par exemple avec le package awt: des classes sont developpes sur une station avec un serveur X et elles definissent betement un import vers awt car un developpeur n'a pu resister a la tentation d'utiliser la classe java.awt.Rectangle pour stocker deux entiers d'un seul coup (idee geniale!) , ensuite elles se retrouvent malencontreusement sur un serveur et hop,,, une belle exception.
Le C/C++ est plus ou moins portable (avec une compil en plus) suivant les librairies sur lesquels ont s'appuie. Je n'ai pas assez d'experience en dev C/C++ pour aller plus loin que ca mais en java les seuls problemes de portabilites que je connaisse ont ete provoque soit par:
- des bugs de la jvm, de plus en plus rare et comme Traumat, je n'en ai pas croise un seul dans la core api ces 5 dernieres annees.
- des problemes plus specifiques, genre windows ne supporte pas les chemins d'acces de plus de 255 caracteres mais l'api java permet de definir de tels chemins. Dans ce cas, que devrait faire sun, difficile a dire!
- des "maladresses" de developpeur: genre on extrait un morceau d'url /x/y/z qu'on veut separer en x/y et z et on utilise les methodes getAbsoluteName() et getName() de java.io.File pour ca. Ensuite on reconstruie une url avec x/y. Mauvaise idee, la classe File s'adapte au systeme d'exploitation et la partie getAbsoluteName() retourne x\y sous windows et x/y sous linux. Mais bon, la c'est une tres mauvaise utilisation de l'API java.
Donc en evitant les betises, je trouve java plutot bien portable.
[^] # Re: Un intérêt pour Linux
Posté par zipit74 . En réponse à la dépêche Un point sur Java et l'Open-Source. Évalué à 4.
On ne peut meme pas dire que ca soit un probleme de portabilite vu que ton code aurait marche sur un linux installe avec un serveur X. C'est un classique par exemple avec le package awt: des classes sont developpes sur une station avec un serveur X et elles definissent betement un import vers awt car un developpeur n'a pu resister a la tentation d'utiliser la classe java.awt.Rectangle pour stocker deux entiers d'un seul coup (idee geniale!) , ensuite elles se retrouvent malencontreusement sur un serveur et hop,,, une belle exception.
Le C/C++ est plus ou moins portable (avec une compil en plus) suivant les librairies sur lesquels ont s'appuie. Je n'ai pas assez d'experience en dev C/C++ pour aller plus loin que ca mais en java les seuls problemes de portabilites que je connaisse ont ete provoque soit par:
- des bugs de la jvm, de plus en plus rare et comme Traumat, je n'en ai pas croise un seul dans la core api ces 5 dernieres annees.
- des problemes plus specifiques, genre windows ne supporte pas les chemins d'acces de plus de 255 caracteres mais l'api java permet de definir de tels chemins. Dans ce cas, que devrait faire sun, difficile a dire!
- des "maladresses" de developpeur: genre on extrait un morceau d'url /x/y/z qu'on veut separer en x/y et z et on utilise les methodes getAbsoluteName() et getName() de java.io.File pour ca. Ensuite on reconstruie une url avec x/y. Mauvaise idee, la classe File s'adapte au systeme d'exploitation et la partie getAbsoluteName() retourne x\y sous windows et x/y sous linux. Mais bon, la c'est une tres mauvaise utilisation de l'API java.
Donc en evitant les betises, je trouve java plutot bien portable.