Si estoy implementando en servidores con WebSphere 6.1 (Java 1.5), ¿debería usar el JDK de IBM en mi cuadro de compilación? ¿O compilará JDK de Sun el mismo binario?¿Importa con qué JDK del proveedor compila?
Si debería usar IBM, ¿dónde puedo obtener la versión de Windows x64?
Intentaré en todo lo posible mantener el desarrollo lo más cercano posible a la producción. Los JDK de Ibm y Sun ciertamente satisfacen la certificación SDK, pero de ninguna manera son idénticos. Su instrumentación y administración de memoria son al menos ligeramente diferentes. Si nada más, los errores en el JDK serán diferentes, por lo que su código solo puede tropezar en un escenario frente a otro. Probablemente también ocurra a las 4 a. M., Y cuando la luna esté llena, especialmente cuando haya terminado la empresa.
No puedo decirle dónde conseguir jdk de IBM, pero si tiene una licencia para websphere en su empresa, debe tener un contacto en IBM para obtener un enlace a ese JDK.
Buena suerte, y siempre trate de minimizar las diferencias donde sea posible.
No debería hacer ninguna diferencia. Probablemente no sea exactamente el mismo binario pero 100% compatible. Supongo que está utilizando bibliotecas externas de todos modos como log4j o hibernate o lo que sea y que no están compiladas con IBM JDK.
Existen diferencias en los JRE, sin embargo. Por ejemplo, recuerdo que cuando enumeré métodos o campos de una clase usando reflexión, el IBM JRE solía darlos en un orden diferente al de Sun.
Usaría el mismo JDK para compilar que se utilizará cuando se implemente la aplicación (si usted tiene control sobre eso).
Los binarios pueden ser diferentes si el compilador es diferente, pero deben ser semánticamente idénticos. No sé si IBM escribió su propio compilador. El JRockit JDK realmente usa el compilador de Sun pero las JVM son diferentes. Entonces con JRockit los binarios son idénticos.
Si la aplicación se usa con diferentes JDK en tiempo de ejecución, seguiría compilando con la que cree que se utilizará en el momento de la implementación la mayor parte del tiempo y realizar algunas pruebas de tiempo de ejecución con diferentes JDK.
Deben compilar a la misma especificación de bytecode, aunque pueden compilar diferentes bytecode (de forma similar a como diferentes compiladores de C generan código de máquina diferente). No creo que haya ningún problema para ejecutar el código resultante: compilé Java 1.4 en una Mac y luego lo implementé en IBM J9 ejecutándose en un PocketPC antes sin problemas (esto fue antes de que J9 pudiera manejar el código de bytes de Java 5) .
Independientemente, definitivamente convertiría su plataforma de compilación en una viñeta en su archivo Léame para que su cliente pueda ver si es un problema.
Alternativamente, podría compilar e implementar con ANT, y usar el JDK de Sun con ANT.
La compilación con cualquier JDK no debería causar un problema a menos que esté haciendo referencia a clases fuera de java. * Y javax. * Pacakges (que no debería ser). Por supuesto, siempre hay una posibilidad de discrepancia entre JDK del proveedor y la especificación que podría causar algunos errores de tiempo de ejecución realmente extraños que son difíciles de rastrear, pero nunca he visto esto antes en mi experiencia.
Recomendaría ejecutar cualquier suite de pruebas que tenga utilizando el JRE de destino, ya que los comportamientos de tiempo de ejecución difieren entre los proveedores mucho más a menudo que la semántica de compilación.
JDK están compilando el código a un código de bytesy no directamente al código de máquina . Se espera que los compiladores de diferentes proveedores generen código compatible entre proveedores. Por ejemplo, el compilador de IBM para JDK1.5 producirá código que se ejecuta en JDK 1.5 de SUN y posteriormente sin ningún problema.
Otro problema es cómo los compiladores optimizan el bytecode, no tengo información de que algunos compiladores tengan una mejor optimización que otros. La mayor parte de la optimización se realiza durante el tiempo de ejecución mediante JVM (por ejemplo, estrategias JIT (just-in-time) o AOT (anticipación)).
Al haber trabajado con WebSphere durante mucho tiempo, la versión del JDK es muy importante. WebSphere 6.1 se envía con IBM JDK 1.5 (o es 5). Cuando aplica parche a WebSphere, también hay parches equivalentes para el JDK. Si bien puede funcionar con una versión diferente del JDK (incluso un proveedor diferente), dudo que reciba mucho soporte de IBM si algo sale mal.
Si necesita una JVM de 64 bits, sugeriría que probablemente haya una compilación de 64 bits, aunque no puedo comentar sobre Windows específicamente, puedo decir que hay una versión de WebSphere 6.1 de 64 bits tanto para AIX como para Linux.
La mejor respuesta es consultar con el proveedor y ver si son compatibles con su configuración. Lo que no desea hacer es ponerlo en funcionamiento, luego tener un problema en vivo, solicitar asistencia y descubrir que tiene un entorno no compatible.
IBM JDK se envía con J9 VM y SUN JDK se ejecuta en Hotspot VM que tienen diferentes algoritmos para funcionar. Es posible que su aplicación no realice lo mismo si implementa y sintoniza SUN JDK y su producción utiliza IBM JDK para WAS. Consulte con los proveedores y abra un ticket, háganos saber cómo funciona.