sun - jdk - jre 11 download

¿Por qué hay muchas implementaciones de JRE? (11)

Me preguntaba ... Hay JRE de Sun, JRE de IBM, JRE de BEA, JRE de Oracle y algunos JRE menos conocidos en el mercado. ¿Por qué hay tantas implementaciones de JRE? ¿El hecho de que Sun haya abierto las plataformas Java significa que habrá un JRE / JDK abierto? ¿O vamos hacia lo que sucedió con Linux y sus muchas distribuciones?

¿Por qué hay más de un compilador de C? ¿Por qué hay más de una implementación de Ruby? Las diferentes implementaciones permiten que diferentes equipos exploren diferentes posibilidades de optimización, etc. Por ejemplo, estoy bastante seguro de que en un momento el IBM JRE fue mucho más rápido que el Sun para el punto flotante. Otras implementaciones pueden tener características especiales para precompilación, etc.

En cuanto a si OpenJDK reducirá la variedad disponible, es difícil de decir. Sin embargo, me complace que la variedad exista: una competencia como esta ayuda a todos.

Algunas implementaciones de JRE se adaptan para adaptarse al mercado de sistemas integrados, donde el tamaño de la memoria es a veces más importante que la velocidad bruta.

Incluso Sun tiene al menos dos versiones de JRE, una versión de servidor que tiene un mejor rendimiento pero usa más memoria y tarda más tiempo en iniciarse, y una versión de cliente que está optimizada para ejecutar aplicaciones más pequeñas.

BEA hizo uno porque necesitaba mejoras de rendimiento específicas para su servidor WebLogic. Otros tienen por las mismas razones. Todos piensan que pueden hacerlo un poco mejor, y todos necesitan algo especial del JRE. Sun tiene especificaciones para JRE, y todas las que conozco se ajustan a ella. Por lo tanto, cualquier código de Java o Scala que escriba debería funcionar.

Ah, y openJDK no resolverá los problemas de todos, por lo que aún habrá múltiples JRES de propiedad.

Hay muchos JRE porque hay muchas colecciones diferentes de requisitos por parte de personas que usan Java. Los usos del servidor a menudo usarán JRockit anteriormente BEA, ahora Oracle), ya que está específicamente ajustado para el uso del servidor. Las ofertas de Sun están sintonizadas para funcionar bien para cualquier uso, pero las ofertas de terceros pueden ajustarse para funcionar mejor que Sun''s JRE en usos específicos o de nicho.

Esto es diferente de Linux y sus muchas distribuciones debido a las garantías que establecen los requisitos de licencia de Sun para las implementaciones de Java de terceros. Eliminando errores, ya sabes cómo funcionarán todos los JRE de Java. Las especificaciones son bastante estrictas.

Hay otros JRE como OpenJDK, que es de código abierto. También hay versiones J2ME que se ejecutan en dispositivos móviles y cosas como reproductores de Blu-ray.

Java fue diseñado para comenzar como una especificación estándar que cualquier persona era libre de implementar. El objetivo era descargar algo de trabajo de Sun para hacerlo más universal (ya que los proveedores de SO / plataforma pueden escribir sus propios JRE), pero lo más importante, para permitir la competencia y, por lo tanto, mejorar el rendimiento.

En gran medida, este modelo funcionó bastante bien. Muchas de las técnicas de recolección de basura más nuevas se desarrollaron, probaron y probaron inicialmente en JRE orientadas a la investigación. Lo mismo ocurre con otras optimizaciones (por ejemplo, IBM Researched utilizado para mantener un JRE por separado). Otros proveedores crearon implementaciones que fueron optimizadas para una arquitectura particular.

Estoy de acuerdo en que, en algún momento, tal vez cuando Java se volvió menos popular debido a MS .NET o debido a los propios problemas de Sun, los avances dejaron de estar integrados desde la implementación hasta la implementación, lo que crea un caos para los usuarios.

No creo que abrir el JDK signifique que el número de JRE seguirá siendo el mismo o disminuirá. En todo caso, según la experiencia de la comunidad con el software de código abierto (¿Linux, por ejemplo?), Probablemente tendremos aún más JRE.

¿Y por qué no? La competencia es algo bueno.

Otra razón además de abordar diferentes necesidades de rendimiento es la estrategia y el modelo de negocio de Sun para Java. Si otra implementación desea utilizar la marca de Java, debe estar certificada y autorizada por Sun. Sun desea ver que Java se use en todas partes y se da cuenta de que no pueden escribir una implementación que cubra todas las necesidades posibles. Al promover diferentes implementaciones de las especificaciones de Java, Sun fomenta el crecimiento de la comunidad y ayuda a garantizar la supervivencia a largo plazo de Java.

Porque sirven diferentes necesidades? Los JRE de Sun son los principales para Windows y Linux para el escritorio y muchas aplicaciones de servidor. BEA tiene algunas características agradables de administración y un rendimiento mejorado para muchos casos (a costa de mayores tiempos de inicio y mayor consumo de memoria). IBM también es teóricamente más rápido y está preparado para ejecutar bien sus servidores de aplicaciones. Eso le da unos pocos usuarios en Linux y Windows, pero es muy popular en plataformas que no son compatibles con Sun (IBM AIX, OS400, etc.).

Creo que el "Oracle JRE" al que te refieres es solo un BEA JRE renombrado después de la compra de BEA.

Al final, todos son compatibles con Sun TCK, y en general comparten mucho código (bibliotecas Java, Swing, en algunos casos Hotspot) así como un grado extremadamente alto de compatibilidad. En la práctica, son al menos tan compatibles entre sí como las diversas versiones de Windows (Vista vs. Servidor, etc.).

Es probable que OpenJDK gane popularidad entre los usuarios de Linux debido a que es completamente de código abierto, sin embargo, es poco probable que sustituya el JDK de Sun en el futuro inmediato en plataformas no Linux por varias razones (la representación de fuentes gratuitas es ligeramente más débil que la de código cerrado, etc. )

Y luego, por supuesto, Sun no lanza la VM para la Mac, ya que Apple se las arregla por sí misma.

Entonces, ¿es esta la situación con las distribuciones de Linux? Realmente no lo creo, por un par de razones:

Prueba: cada uno de estos pasa un TCK para asegurar la compatibilidad con el estándar. Las distribuciones de Linux hacen muy poco esfuerzo para mantener una compatibilidad similar.
Versiones - Java 1.6 == Sun 1.6 == IBM 1.6 == Cualquier Java 1.6. Linux tiene muy poca estandarización en términos de control de versiones para asegurar la compatibilidad entre versiones. LSB intenta hacer esto, pero aún no está completamente allí.
Coherencia: con la excepción de las plataformas impares para las cuales las herramientas jdk estándar es poco probable que funcionen de la manera "estándar" (por ejemplo, AS / 400), cada una se siente exactamente igual. Cada uno tiene el mismo "javac" y otras herramientas para cumplir con los estándares de Sun. En la práctica, son mucho más similares que las distribuciones de Linux.

Por lo tanto, supongo que mi respuesta es que son diferentes debido a la necesidad y la gran flexibilidad que ofrece la plataforma. Pero no es como el tipo de entorno incompatible que vemos en el mundo de Linux.

Sun es compatible con Solaris, Windows y Linux con sus JRE y JDK. Otros proveedores querían que sus plataformas fueran compatibles, por lo que escribieron las suyas propias, generalmente basadas en tecnología licenciada por Sun. Es por eso que Apple desarrolló una JVM, querían soporte para OS X. Los desarrolladores de código abierto querían que Java fuera compatible con BSD y con plataformas Linux que no fueran x86 y Sparc (por ejemplo, PowerPC). IBM quería una JVM en z / OS y AIX y, dado que la estaban desarrollando de todos modos, también podrían lanzarla para Windows y Linux.

¿JRE de Oracle es solo JRockit, que adquirieron con BEA?

Si tiene dudas, solo use la VM Java estándar de Sun / Oracle.

Recuerde que Sun no abrió completamente el código fuente de Java, algunas partes se cerraron.

Razones principales para implementaciones de VM de terceros
- Soporta plataformas no soportadas por el sol
- Plataformas cerradas (Mac, la suya le da una mejor integración del sistema operativo para que no pueda quejarse).
- Restricciones de licencia (no se puede distribuir por distribuciones)
- Política de distribución de SO (Fedora solo proporciona software libre y abierto)
- Simplemente tratando de competir y hacer una mejor máquina virtual Java
- Optimización / ampliación para una plataforma (Android)