para - java standard edition

¿Qué es Java EE realmente? (5)

Java EE tiene esta "cubierta misteriosa" a su alrededor para los desarrolladores más jóvenes de Java, uno que estuve tratando de superar por un tiempo con poco éxito.

La confusión surge de:

Java EE parece ser tanto una biblioteca como una plataforma: existen múltiples formas de "obtener" la biblioteca Java EE, generalmente de algo como la descarga Java EE SDK de Oracle. Sin embargo, la biblioteca Java EE no funcionará, ni compilará a menos que su código se ejecute o tenga acceso a un servidor de aplicaciones Java EE (como JBoss, GlassFish, Tomcat, etc.). ¿Por qué? ¿Las bibliotecas no pueden funcionar fuera del entorno del servidor de aplicaciones? ¿Por qué necesito algo masivo como JBoss solo para compilar código simple para enviar un correo electrónico?
¿Por qué las bibliotecas Java EE no son "estándar" y se incluyen en la descarga JVM normal y / o el SDK?
¿Por qué hay tantas ofertas de Java EE cuando realmente solo hay dos sabores principales de Java estándar (Oracle JVM / SDK | OpenJDK JVM / JDK)?
¿Qué se puede hacer con Java EE que no pueden hacer con Java estándar?
¿Qué se puede hacer con Java estándar que no pueden hacer con Java EE?
¿Cuándo un desarrollador decide que "necesita" Java EE?
¿Cuándo un desarrollador decide que no necesita Java EE?
¿Por qué la versión de la biblioteca Java EE no está sincronizada con las versiones de la biblioteca Java estándar (Java EE 6 vs. Java 7)?

Gracias por ayudarme a limpiar el flog!

¿Qué es Java EE?

Comencemos desde la definición de canonicidad en wiki:

Java Platform, Enterprise Edition o Java EE es la plataforma de computación Java empresarial de Oracle. La plataforma proporciona un entorno API y de tiempo de ejecución para desarrollar y ejecutar software empresarial, incluidos servicios web y de red, y otras aplicaciones de red seguras, escalables, confiables y de múltiples niveles a gran escala.

El punto principal aquí es que Java EE es una plataforma que proporciona una API, no una biblioteca concreta.

¿Qué necesita Java EE?

El principal alcance de Java EE son las aplicaciones basadas en red, a diferencia de Java SE orientado al desarrollo de aplicaciones de escritorio con soporte de red simple. Esta es la principal diferencia entre ellos. Escalabilidad, mensajería, transacción, soporte de BD para cada aplicación ... la necesidad en todo esto ha aumentado con la evolución de la red. Por supuesto, muchas de las soluciones listas que proporciona Java SE son útiles para el desarrollo de redes, por lo que Java EE amplía Java SE.

¿Por qué necesitamos servidores de aplicaciones para ejecutar nuestro código?

¿Por qué necesitamos sistemas de operación? Porque hay mucho trabajo doloroso con el hardware que tenemos que hacer para hacer una aplicación aún más simple. Y sin sistema operativo, debes hacerlo una y otra vez. El SO excesivamente simplificado es solo un contenedor programático, que nos proporciona un contexto global para ejecutar nuestras aplicaciones.

Y esto es lo que son los servidores de aplicaciones. Nos permiten ejecutar nuestras aplicaciones en su contexto y nos proporcionan una gran cantidad de funcionalidades de alto nivel que son necesarias para las aplicaciones de red de alta carga empresarial. Y no queremos escribir nuestras propias bicicletas para resolver este problema, queremos escribir un código que satisfaga nuestras necesidades comerciales.

Otro ejemplo aquí podría ser JVM para Java.

¿Por qué Java EE no contiene el servidor de aplicaciones integrado?

Es difícil de decir para mí Creo que fue hecho para más flexibilidad. Java EE dice lo que deben hacer, ellos deciden cómo hacerlo.

¿Por qué JVM no incluye Java EE?

Porque ellos dirigieron a diferentes sectores del mercado. Java EE tiene una gran cantidad de funcionalidades que no necesitan los escritorios habituales.

¿Por qué hay tantas ofertas de Java EE?

Porque Java EE solo describe el comportamiento. Todos pueden implementarlo.

¿Qué se puede hacer con Java EE que no pueden hacer con Java SE?

Para conquistar internet Es realmente difícil de hacer con los applets y sockets de Java SE :)

¿Qué se puede hacer con Java SE que no pueden hacer con Java EE?

Como se mencionó anteriormente, Java EE amplía Java SE, por lo que con Java EE debería poder hacer todo lo que esté disponible para Java SE.

¿Cuándo un desarrollador decide que "necesita" Java EE?

Cuando necesitan el poder de Java EE. Todo lo que se menciona arriba.

¿Cuándo un desarrollador decide que no necesita Java EE?

Cuando escriben una consola o aplicación de escritorio habitual.

¿Por qué las versiones de Java SE y Java EE no están sincronizadas?

Java siempre tuvo problemas con sus nombres y versiones de tecnologías. Entonces esta situación no es una excepción.

A vista de pájaro, Java EE es una plataforma, es decir, algo sobre lo que podemos construir.

Desde una perspectiva más técnica, el estándar Java Enterprise Edition define un conjunto de API comúnmente utilizadas para crear aplicaciones empresariales. Estas API son implementadas por los servidores de aplicaciones, y sí, los diferentes servidores de aplicaciones tienen la libertad de usar diferentes implementaciones de las API de Java EE.

Sin embargo, la biblioteca java ee no funcionará, ni compilará a menos que su código se ejecute o tenga acceso a un servidor de aplicaciones Java EE (como JBoss, GlassFish, Tomcat, etc.).

Compila contra las API de Java EE, por lo que solo necesita esas API en tiempo de compilación. En tiempo de ejecución, también necesitará una implementación de estas API, es decir, un servidor de aplicaciones.

¿Por qué necesito algo masivo como JBoss solo para compilar código simple para enviar un correo electrónico?

Tu no Sin embargo, si desea utilizar la API de Java EE para enviar correo, necesitará una implementación de esa API en tiempo de ejecución. Esto puede ser proporcionado por un servidor de aplicaciones, o provisto por una biblioteca independiente que agregue a su classpath.

¿Por qué las bibliotecas Java EE no son "estándar" y se incluyen en la descarga JVM normal y / o el SDK?

Porque solo las API están estandarizadas, no las implementaciones.

¿Por qué hay tantas ofertas de Java EE?

Porque las personas no están de acuerdo sobre la forma correcta de implementar ciertas características. Porque diferentes proveedores compiten por la cuota de mercado.

¿Qué se puede hacer con Java EE que no pueden hacer con Java estándar?

Ya que las implementaciones de Java EE están compiladas con "Java estándar": nada. Sin embargo, aprovechar las bibliotecas existentes puede ahorrarle un gran esfuerzo si resuelve problemas típicos de la empresa, y el uso de una API estandarizada puede evitar el bloqueo del proveedor.

¿Qué se puede hacer con Java estándar que no pueden hacer con Java EE?

Nada, ya que Java EE incluye Java SE.

¿Cuándo un desarrollador decide que "necesita" Java EE? ¿Cuándo un desarrollador decide que no necesita Java EE?

En términos generales, las API de Java EE resuelven problemas recurrentes típicos en la informática empresarial. Si tiene tales problemas, generalmente tiene sentido utilizar las soluciones estándar, pero si tiene problemas diferentes, se pueden necesitar soluciones diferentes. Por ejemplo, si necesita hablar con una base de datos relacional, debería considerar usar JPA. Pero si no necesita una base de datos relacional, JPA no lo ayudará.

Aquí hay algunas respuestas rápidas a sus preguntas ...

¿Por qué las bibliotecas JavaEE no pueden funcionar sin un servidor de aplicaciones? Los servicios proporcionados por JavaEE (transacciones gestionadas por contenedor, inyección de dependencia gestionada por contenedor, servicio de temporizador, etc.) implican inherentemente servidores de aplicaciones compatibles con JavaEE (por ejemplo: GlassFish, JBoss, WebSphere, etc.). Por lo tanto, las bibliotecas JavaEE no tienen sentido sin tal contenedor. " ¿Por qué necesito algo tan masivo como JBoss solo para compilar código simple para enviar un correo electrónico? " No es así. Hay formas de enviar un correo electrónico sin JavaEE ... Pero si quieres hacerlo de la manera JavaEE, necesitas un contenedor JavaEE.
¿Por qué las bibliotecas JavaEE no están incluidas con la descarga de JavaSE? La misma razón por la que muchas bibliotecas no están incluidas: sería excesivo. Dado que ni siquiera puede usar las bibliotecas JavaEE sin un servidor de aplicaciones, ¿por qué molestarse en incluirlas? JavaEE debe descargarse siempre y cuando un desarrollador instale un servidor de aplicaciones y decida usar JavaEE.
¿Por qué hay tantas ofertas de JavaEE? ¿Hay realmente " tantas " ofertas de JavaEE? Si es así, enumere algunos de ellos. Más exactamente, creo que hay múltiples implementaciones de las mismas API .
¿Qué se puede hacer con JavaEE que no pueden hacer sin Java estándar? Un montón. No puede confiar en un servidor de aplicaciones para administrar transacciones o contextos de persistencia sin JavaEE. No puede permitir que un servidor de aplicaciones administre la inyección de dependencias EJB sin JavaEE. No puede usar un servicio de temporizador administrado de aplicación sin JavaEE. La respuesta a esta pregunta debería dejar muy clara la respuesta a la primera pregunta ... La mayoría de los servicios provistos por JavaEE requieren un contenedor JavaEE.
¿Qué puedes hacer con JavaSE que no puedes hacer con JavaEE? Um ... No sé.
¿Cuándo un desarrollador decide que necesita JavaEE? Esta pregunta es completamente subjetiva ... Pero si necesita alguno de los servicios provistos por JavaEE, comienza a pensar en ello. Si no sabes qué es JavaEE ... probablemente no lo necesites.
¿Cuándo un desarrollador decide que no necesita JavaEE? Ver respuesta anterior.
¿Por qué la versión de la biblioteca JavaEE no está sincronizada con la versión de JavaSE? Buena pregunta. No voy a pretender saber cómo responderlo ... Pero supongo que la respuesta es: "porque no están sincronizados".

Java EE tiene que ver con el concepto de contenedor.
El contenedor es un contexto de ejecución dentro del cual se ejecutará su aplicación y que proporciona este último conjunto de servicios. Cada tipo de servicio está definido por una especificación llamada JSR. Por ejemplo, JSR 907, JTA (transacción java API), que proporciona una forma estándar de gestionar las transacciones distribuidas con diferentes recursos.
En general, hay muchas implementaciones diferentes para un JSR determinado, la implementación que utilizará depende del proveedor del contenedor, pero realmente no le importa, ya que está seguro de que el comportamiento respetará el contrato predefinido: la API de JSR.
Entonces, para aprovechar Java EE, necesita ejecutar su aplicación dentro de un contenedor. Los dos principales son EJB y el contenedor de servlets, que están presentes en cualquier servidor de aplicaciones certificado por Java EE.

El objetivo de todo esto es definir un entorno de ejecución estándar que permita empaquetar su aplicación solo con los elementos esenciales, id.est. tu negocio. Evita depender de un conjunto desconocido y diferente de bibliotecas de terceros que tendría que empaquetar y proporcionar con su aplicación de lo contrario, y que pueden ser fuentes de conflicto con otras aplicaciones en el servidor. En Java EE, usted sabe que el contenedor contendrá todos los requisitos no funcionales estándar, como seguridad, transacción, escalabilidad, invocación remota y muchos más (factorizados para todas las aplicaciones que se ejecutan dentro de él) y solo debe basar su trabajo en ellos.

¿Por qué las bibliotecas no pueden funcionar fuera del entorno del servidor de aplicaciones?

En realidad, pueden. La mayoría de las bibliotecas se pueden usar directamente de forma independiente (en Java SE) o incluidas en .war (prácticamente eso es casi siempre Tomcat). Algunas partes de Java EE, como JPA, tienen secciones explícitas en sus respectivas especificaciones que indican cómo deberían funcionar y usarse en Java SE.

En todo caso, no se trata tanto de un entorno de servidor de aplicaciones per se, sino de la presencia de todas las demás bibliotecas y el código de integración que las une.

Por eso, las anotaciones se escanearán una sola vez para todas sus clases en lugar de cada biblioteca (EJB, JPA, etc.) haciendo este escaneo una y otra vez. También debido a eso, las anotaciones CDI se pueden aplicar a los beans EJB y los administradores de entidad JPA se pueden inyectar en ellos.

¿Por qué necesito algo masivo como JBoss solo para compilar código simple para enviar un correo electrónico?

Hay algunas cosas malas con esta pregunta:

Para compilar, solo necesita el jar API, que está por debajo de 1MB para el Perfil web, y un poco más de 1MB para el perfil completo.
Para correr, obviamente necesitas una implementación, pero "masiva" es exagerar las cosas. El OpenJDK, por ejemplo, tiene alrededor de 75 MB y TomEE (una implementación de perfil web que contiene soporte de correo) tiene solo 25 MB. Incluso GlassFish (una implementación de perfil completo) tiene solo 53MB.
El correo funciona perfectamente desde Java SE (y, por lo tanto, Tomcat) y utiliza el correo independiente.jar y la activación.jar .

¿Por qué las bibliotecas Java EE no son "estándar" y se incluyen en la descarga JVM normal y / o el SDK?

Java EE en cierto modo fue uno de los primeros intentos de dividir el ya enorme JDK en fragmentos que son más fáciles de administrar y descargar. La gente ya se queja de que las clases gráficas (AWT, Swing) y Applets están dentro del JRE cuando todo lo que hacen es ejecutar algunos comandos en un servidor sin cabeza. ¿Y luego también quiere incluir todas las bibliotecas Java EE en el JDK estándar?

Con el lanzamiento final del soporte de modularidad, tendremos un JRE base pequeño con muchas cosas que se pueden instalar por separado como paquetes. Tal vez un día muchas o incluso todas las clases que ahora componen Java EE también sean un paquete. El tiempo dirá.

¿Por qué hay tantas ofertas de Java EE cuando realmente solo hay dos sabores principales de Java estándar (Oracle JVM / SDK | OpenJDK JVM / JDK)?

Hay más que solo dos sabores de Java SE. Existe al menos el IBM JDK, el anterior BEA one (JRocket, que se está fusionando con Oracle / Sun one debido a la adquisición), varias otras implementaciones de código abierto y una gran cantidad de implementaciones para uso integrado.

La razón por la que Java SE y EE son una especificación es que muchos proveedores y organizaciones pueden implementarla y, por lo tanto, fomenta la competencia y mitiga el riesgo de que los proveedores se acoplen.

En realidad, no es diferente con los compiladores C y C ++, donde tiene muchas ofertas competidoras y todas se adhieren al estándar C ++.

¿Por qué la versión de la biblioteca Java EE no está sincronizada con las versiones estándar de la biblioteca Java (Java EE 6 vs. Java 7)?

Java EE se basa en Java SE, por lo que queda rezagado. Las versiones sí se corresponden. Java EE 5 requiere Java SE 5. Java EE 6 requiere Java SE 6, y así sucesivamente. Es solo que sobre todo cuando Java SE X es actual, Java EE X-1 es actual.