Si je me déploie sur des serveurs avec WebSphere 6.1 (Java 1.5), dois-je utiliser le JDK d'IBM dans ma boîte de construction? Ou le JDK de Sun compilera-t-il au même binaire?Le JDK du constructeur est-il important?
Si je devais utiliser IBM, où puis-je obtenir la version Windows x64?
Je voudrais autant que possible essayer de garder le développement aussi proche de la production que possible. Les JDK d'Ibm et Sun satisfont certainement à la certification SDK, mais ils ne sont en aucun cas identiques. Leur instrumentation et la gestion de la mémoire sont au moins légèrement différentes. Si rien d'autre, les bogues dans le JDK seront différents, que votre code ne peut trébucher dans un scénario par rapport à un autre. Cela ne se produira probablement qu'à 4 heures du matin, et quand la lune est pleine surtout quand vous avez de la compagnie.
Je ne peux pas vous dire où trouver IBM jdk, mais si vous avez une licence websphere dans votre entreprise, vous devriez avoir un contact chez IBM pour vous donner un lien vers ce JDK.
Bonne chance, et toujours essayer de minimiser les différences si possible.
Cela ne devrait pas faire de différence. Ce ne sera probablement pas exactement le même binaire mais 100% compatible. Je suppose que vous utilisez des bibliothèques externes de toute façon, comme log4j ou peut-être hibernate ou autre, et celles-ci ne sont pas construites en utilisant IBM JDK.
Cependant, il existe des différences dans les JRE. Par exemple, je me souviens que lorsque j'énumérais des méthodes ou des champs d'une classe en utilisant la réflexion, l'IBM JRE me les donnait dans un ordre différent de celui du Soleil.
J'utiliserais le même JDK pour construire qui sera utilisé lors du déploiement de l'application (si vous avez le contrôle).
Les binaires peuvent être différents si le compilateur est différent, mais ils doivent être sémantiquement identiques. Je ne sais pas si IBM a écrit son propre compilateur. Le JDK JRockit utilise réellement le compilateur Sun mais les JVM sont différentes. Donc avec JRockit les binaires sont identiques.
Si l'application est utilisée avec différents JDK au moment de l'exécution, je construirais toujours avec celle que vous penserez être utilisée au moment du déploiement la plupart du temps et effectuer des tests d'exécution avec différents JDK.
Ils doivent être compilés selon la même spécification bytecode, bien qu'ils puissent compiler un bytecode différent (de la même manière que différents compilateurs C génèrent un code machine différent). Je ne pense pas qu'il y aurait de problèmes à exécuter le code résultant - j'ai compilé Java 1.4 sur un Mac puis déployé sur le J9 d'IBM fonctionnant sur un PocketPC sans problème (c'était avant que J9 puisse gérer le bytecode Java 5) . Quoi qu'il en soit, je ferais certainement de votre plate-forme de compilation un point sur votre fichier Lisez-moi afin que votre client puisse voir si c'est un problème. Alternativement, vous pouvez construire et déployer avec ANT, et utiliser le JDK de Sun avec ANT.
La compilation avec n'importe quel JDK ne devrait pas poser de problème à moins que vous ne référençiez des classes en dehors de java. * Et javax. * Pacakges (ce que vous ne devriez pas être.) Bien sûr, il y a toujours une différence JDK du constructeur et la spécification qui pourrait causer des erreurs d'exécution vraiment bizarres qui sont difficiles à traquer, mais je n'ai jamais vu cela auparavant dans mon expérience.
Je recommanderais d'exécuter toutes les suites de tests utilisant le JRE cible car les comportements d'exécution diffèrent beaucoup plus souvent entre les fournisseurs que les sémantiques de compilation.
JDKs compilent votre code à un bytecode et non directement à code machine. On s'attend à ce que les compilateurs de différents fournisseurs génèrent du code compatible entre fournisseurs. Par exemple, le compilateur IBM pour JDK1.5 produira du code qui s'exécute sur le JDK 1.5 et ultérieur de SUN sans aucun problème.
Un autre problème est de savoir comment les compilateurs optimisant le bytecode, je n'ai pas d'informations que certains compilateurs effectuant une meilleure optimisation que d'autres. La plus grande partie de l'optimisation est effectuée pendant l'exécution par la JVM (par exemple, les stratégies JIT (just-in-time) ou AOT (en avance).
Après avoir longtemps travaillé avec WebSphere, la version du JDK est très importante. WebSphere 6.1 est livré avec un IBM JDK 1.5 (ou 5). Lorsque vous corrigez WebSphere, il existe également des correctifs équivalents pour le JDK. Bien qu'il puisse fonctionner avec une version différente du JDK (même un fournisseur différent), je doute que vous obtiendrez beaucoup de soutien d'IBM si quelque chose ne va pas. Si vous avez besoin d'une JVM 64 bits, je suggérerais qu'il existe probablement une version 64 bits, alors que je ne peux pas commenter spécifiquement Windows, je peux vous dire qu'il existe une version WebSphere 6.1 64 bits pour AIX et Linux.
La meilleure réponse est de vérifier auprès du fournisseur et de voir si elles prendront en charge votre configuration. Ce que vous ne voulez pas faire est de le faire fonctionner, puis avoir un problème en direct, appelez le support et découvrez que vous avez un environnement non pris en charge.
L'IBM JDK livré avec J9 VM et SUN JDK s'exécute sur une machine virtuelle Hotspot dont les algorithmes sont différents. Votre application peut ne pas fonctionner de la même manière si vous déployez et synchronisez SUN JDK et que votre production utilise IBM JDK for WAS. Vérifiez auprès des vendeurs et ouvrez un ticket, laissez-nous savoir comment ça se passe.