Java est-il totalement indépendant de la plate-forme ?

Question

Java est-il complètement indépendant de la plate-forme ?

Si ce n'est pas le cas, quelles précautions doivent être prises pour que votre code écrit en Java puisse fonctionner sur plusieurs plateformes. Fondamentalement, il devrait fonctionner sur les plates-formes ciblées comme Windows (diverses versions), Linux (toutes les saveurs), Mac et Solaris.

Answer 1

Bien qu'en pratique, la plupart des codes d'octets compilés soient indépendants de la plate-forme, l'expérience acquise au cours de mes 12 années de développement sur la plate-forme Java m'a appris qu'il existe encore des particularités d'une plate-forme à l'autre.

Par exemple, lors du développement d'une application Java 1.4 Swing pour PC et MacOSX, le comportement des boîtes de dialogue était différent si le cadre parent est nul.

Un autre exemple pourrait être le travail avec le système de fichiers et les fichiers en général. L'API Java dispose de méthodes permettant de protéger le développeur des différences entre les séparateurs de chemin ( / vs \ ). Lorsque vous écrivez dans un fichier, il est important d'utiliser l'API FileWriter comme prévu afin que les caractères de retour et autres soient générés correctement pour la plate-forme sur laquelle ils sont écrits.

Ainsi, bien que la devise soit "écrire une fois, exécuter n'importe où", mon expérience m'a montré que pour les environnements de production, il faut écrire une fois, test partout.

Par conséquent, le fait de disposer de solides tests unitaires et d'intégration peut y contribuer, car vous pouvez exécuter ces tests sur les différentes plateformes sur lesquelles vous souhaitez distribuer votre logiciel.

Malgré quelques problèmes mineurs ici et là, il est agréable de voir votre code fonctionner sur Linux, Unix, Windows et MacOSX (BSD Unix) en utilisant les mêmes JARs.

Answer 2

Comme l'a souligné djacobson, la réponse est un "oui" nuancé. Dans la plupart des cas, les développeurs Java n'ont pas à se soucier des dépendances de plate-forme. Cependant, vous pouvez rencontrer des problèmes lorsque vous avez affaire à des API qui gèrent les fonctions traditionnelles du système d'exploitation et de la plate-forme.

Lorsqu'il s'agit d'E/S de fichiers, par exemple, il est facile de rendre votre code dépendant de la plate-forme en ignorant les différences entre les séparateurs de fichiers/chemins d'une plate-forme à l'autre (c'est-à-dire en utilisant les séparateurs d'E/S de fichiers). '\' plutôt que File.separator ).

Answer 3

Dans la plupart des cas, oui. Puisque Java compile en bytecode qui est exécuté par sa machine virtuelle, il peut généralement doit se comporter de la même manière quel que soit le système qui se trouve sous la machine virtuelle.

Cependant. Même les machines virtuelles ne sont pas à l'abri bogues . Une recherche rapide sur Google donne par exemple les résultats suivants :

http://www.ibm.com/developerworks/java/library/j-diag0521.html

Les différences de comportement peuvent varier d'une JVM à l'autre. Avec un peu de chance, vous ne vous retrouverez pas avec un code qui dépend de l'un de ces cas... mais une recherche minutieuse vaut la peine pour connaître les limites de votre infrastructure.

Answer 4

Votre problème ne sera pas l'exécution de votre code, mais plus probablement les hypothèses que vous devez faire sur les chemins de fichiers, les commandes externes disponibles (si vous en avez besoin), les autorisations de fichiers nécessaires et d'autres facteurs externes qui n'entrent pas vraiment dans le domaine des problèmes "Java". À moins que vous ne prévoyiez d'utiliser le code natif (via JNI) de manière intensive, Java ne sera pas votre problème, c'est votre environnement qui le sera. Ce qui nous ramène au vieil adage : "écrire une fois, tester partout".

Answer 5

Les priorités de filetage sont une chose à considérer. D'autres systèmes d'exploitation, comme Solaris par exemple, ont plus de priorités de threads que Windows. Donc, si vous travaillez beaucoup sur le multithreading, le système d'exploitation est un élément qui peut affecter le comportement du programme.