O que é Java EE realmente? [fechadas]

Java EE tem essa "mortalha misteriosa" para os desenvolvedores Java mais jovens - uma que venho tentando levantar há um bom tempo, com pouco sucesso.

A confusão surge de:

• O Java EE parece ser uma biblioteca e uma plataforma - existem várias maneiras de "obter" a biblioteca Java EE, normalmente de algo como o download do Java EE SDK da Oracle. No entanto, a biblioteca Java EE não funcionará, nem será compilada, a menos que seu código esteja sendo executado ou tenha acesso a um servidor de aplicativos Java EE (como JBoss, GlassFish, Tomcat, etc). Por quê? As bibliotecas não podem funcionar fora do ambiente do servidor de aplicativos? Por que preciso de algo enorme como JBoss apenas para compilar um código simples para enviar um e-mail?

• Por que as bibliotecas Java EE não são "padrão" e estão incluídas no download JVM regular e / ou SDK?

• Por que existem tantas ofertas de Java EE quando, na verdade, existem apenas dois tipos principais de Java padrão (Oracle JVM / SDK | OpenJDK JVM / JDK)?

• O que se pode fazer com o Java EE que não pode ser feito com o Java padrão?

• O que se pode fazer com o Java padrão que não pode ser feito com o Java EE?

• Quando um desenvolvedor decide que "precisa" do Java EE?

• Quando um desenvolvedor decide que não precisa do Java EE?

• Por que a versão da biblioteca Java EE não está em sincronia com as versões da biblioteca Java padrão (Java EE 6 vs. Java 7)?

Obrigado por me ajudar a limpar o flog!

Por que as bibliotecas não funcionam fora do ambiente do servidor de aplicativos?

Na verdade, eles podem. A maioria das bibliotecas pode ser usada diretamente autônoma (em Java SE) ou incluída em um .war (quase sempre é o Tomcat). Algumas partes do Java EE, como JPA, têm seções explícitas em suas respectivas especificações que informam como devem funcionar e ser usadas no Java SE.

Na verdade, não é tanto um ambiente de servidor de aplicativos em si que está em jogo aqui, mas a presença de todas as outras bibliotecas e o código de integração que as une.

Por causa disso, as anotações serão varridas apenas uma vez para todas as suas classes, em vez de cada biblioteca (EJB, JPA, etc) fazendo essa varredura repetidamente. Também por causa disso, as anotações CDI podem ser aplicadas aos beans EJB e os gerenciadores de entidade JPA podem ser injetados neles.

Por que preciso de algo enorme como JBoss apenas para compilar um código simples para enviar um e-mail?

Existem algumas coisas erradas com esta pergunta:

1. Para compilar, você só precisa do jar da API, que está abaixo de 1 MB para o Perfil da Web e um pouco mais de 1 MB para o perfil completo.
2. Para rodar você obviamente precisa de uma implementação, mas "massivo" é um exagero. O OpenJDK, por exemplo, tem cerca de 75 MB e o TomEE (uma implementação de Perfil da Web que contém suporte para correio) tem apenas 25 MB. Mesmo GlassFish (uma implementação de perfil completo) tem apenas 53 MB.
3. O Mail funciona perfeitamente no Java SE (e, portanto, no Tomcat), bem como usando o mail.jar e o activation.jar independentes .

Por que as bibliotecas Java EE não são "padrão" e estão incluídas no download JVM regular e / ou SDK?

O Java EE, de certa forma, foi uma das primeiras tentativas de dividir o já enorme JDK em blocos que são mais fáceis de gerenciar e baixar. As pessoas já estão reclamando que as classes gráficas (AWT, Swing) e Applets estão dentro do JRE quando tudo o que fazem é executar alguns comandos em um servidor headless. E então você também deseja incluir todas as bibliotecas Java EE no JDK padrão?

Com o eventual lançamento do suporte à modularidade, teremos apenas um pequeno JRE básico com muitas coisas instaláveis ​​separadamente como pacotes. Talvez um dia muitas ou mesmo todas as classes que agora compõem o Java EE também o sejam. O tempo vai dizer.

Por que existem tantas ofertas de Java EE quando, na verdade, existem apenas dois tipos principais de Java padrão (Oracle JVM / SDK | OpenJDK JVM / JDK)?

Existem mais do que apenas dois tipos de Java SE. Há pelo menos o IBM JDK, o BEA anterior (JRocket, que está sendo incorporado ao Oracle / Sun por causa da aquisição), várias outras implementações de código aberto e uma série de implementações para uso integrado.

A razão por trás do Java SE e EE serem uma especificação é que muitos fornecedores e organizações podem implementá-lo e, portanto, incentiva a competição e mitiga o risco de dependência do fornecedor.

Realmente não é diferente com compiladores C e C ++, onde você tem muitas ofertas concorrentes, todas aderindo ao padrão C ++.

Por que a versão da biblioteca Java EE não está em sincronia com os lançamentos da biblioteca Java padrão (Java EE 6 vs. Java 7)

O Java EE é baseado no Java SE, portanto, fica para trás. No entanto, as versões correspondem. Java EE 5 requer Java SE 5. Java EE 6 requer Java SE 6 e assim por diante. Acontece que principalmente quando o Java SE X é atual, o Java EE X-1 é atual.

Aqui estão algumas respostas compostas rapidamente para suas perguntas ...

• Por que as bibliotecas JavaEE não funcionam sem um servidor de aplicativos? Os serviços fornecidos pelo JavaEE (transações gerenciadas por contêiner, injeção de dependência gerenciada por contêiner, serviço de cronômetro, etc.) envolvem inerentemente servidores de aplicativos compatíveis com JavaEE (por exemplo: GlassFish, JBoss, WebSphere, etc ...). Portanto, as bibliotecas JavaEE não servem a nenhum propósito sem esse contêiner. “ Por que preciso de algo tão grande quanto o JBoss apenas para compilar um código simples para enviar um e-mail? ” Você não precisa . Existem maneiras de enviar um e-mail sem JavaEE ... Mas se você quiser fazer isso da maneira JavaEE, você precisa de um container JavaEE.

• Por que as bibliotecas JavaEE não estão incluídas no download do JavaSE? O mesmo motivo pelo qual muitas bibliotecas não estão incluídas: seria um exagero. Já que você não pode usar as bibliotecas JavaEE sem um servidor de aplicativos, por que se preocupar em incluí-las? O JavaEE deve ser baixado se e quando um desenvolvedor instalar um servidor de aplicativos e decidir usar o JavaEE.

• Por que existem tantas ofertas JavaEE? Existem realmente " tantas " ofertas JavaEE? Em caso afirmativo, liste alguns deles. Mais precisamente, acredito que existem várias implementações das mesmas APIs .

• O que se pode fazer com JavaEE que não pode ser feito sem o Java padrão? Grande quantidade. Você não pode confiar em um servidor de aplicativos para gerenciar transações ou contextos de persistência sem JavaEE. Você não pode permitir que um servidor de aplicativos gerencie a injeção de dependência de EJB sem JavaEE. Você não pode usar um serviço de cronômetro gerenciado por aplicativo sem JavaEE. A resposta a esta pergunta deve tornar a resposta à primeira pergunta bastante clara ... A maioria dos serviços fornecidos pelo JavaEE requer um contêiner JavaEE.

• O que você pode fazer com JavaSE que não pode ser feito com JavaEE? Hum ... eu não sei.

• Quando um desenvolvedor decide que precisa do JavaEE? Essa questão é totalmente subjetiva ... Mas se você precisa de algum dos serviços prestados pelo JavaEE, comece a pensar nisso. Se você não sabe o que é JavaEE ... provavelmente não precisa dele.

• Quando um desenvolvedor decide que não precisa do JavaEE? Veja a resposta anterior.

• Por que a versão da biblioteca JavaEE não está sincronizada com a versão JavaSE? Boa pergunta. Não vou fingir que sei responder ... Mas acho que a resposta é: "porque eles não estão sincronizados".

Em uma visão panorâmica, Java EE é uma plataforma, ou seja, algo em que podemos construir.

Tomando uma perspectiva mais técnica, o padrão Java Enterprise Edition define um conjunto de APIs comumente usado para construir aplicativos corporativos. Essas APIs são implementadas por servidores de aplicativos - e sim, diferentes servidores de aplicativos têm liberdade para usar diferentes implementações das APIs Java EE.

No entanto, a biblioteca java ee não funcionará, nem será compilada, a menos que seu código esteja sendo executado ou tenha acesso a um servidor de aplicativos Java EE (como JBoss, GlassFish, Tomcat, etc).

Você compila com as APIs Java EE, portanto, só precisa dessas APIs no momento da compilação. Em tempo de execução, você também precisará de uma implementação dessas APIs, ou seja, um servidor de aplicativos.

Por que preciso de algo enorme como JBoss apenas para compilar um código simples para enviar um e-mail?

Você não. No entanto, se desejar usar a API Java EE para enviar e-mail, você precisará de uma implementação dessa API em tempo de execução. Isso pode ser fornecido por um servidor de aplicativos ou por uma biblioteca independente que você adiciona ao seu classpath.

Por que as bibliotecas Java EE não são "padrão" e estão incluídas no download JVM regular e / ou SDK?

Porque apenas as APIs são padronizadas, não as implementações.

Por que existem tantas ofertas Java EE

Porque as pessoas discordam sobre a maneira certa de implementar determinados recursos. Porque diferentes fornecedores competem por participação no mercado.

O que se pode fazer com o Java EE que não pode ser feito com o Java padrão?

Como as implementações Java EE são construídas com "Java padrão": Nada. No entanto, aproveitar as bibliotecas existentes pode economizar muito esforço se você estiver resolvendo problemas corporativos típicos, e usar uma API padronizada pode evitar o bloqueio de fornecedor.

O que se pode fazer com o Java padrão que não pode ser feito com o Java EE?

Nada, já que o Java EE inclui o Java SE.

Quando um desenvolvedor decide que "precisa" do Java EE? Quando um desenvolvedor decide que não precisa do Java EE?

De modo geral, as APIs Java EE resolvem problemas típicos e recorrentes na computação corporativa. Se você tiver esses problemas, geralmente faz sentido usar as soluções padrão - mas se você tiver problemas diferentes, soluções diferentes podem ser necessárias. Por exemplo, se você precisa se comunicar com um banco de dados relacional, deve considerar o uso de JPA. Mas se você não precisa de um banco de dados relacional, o JPA não o ajudará.

O que é Java EE?

Vamos começar pela definição de canonicidade no wiki:

Java Platform, Enterprise Edition ou Java EE é a plataforma de computação Java empresarial da Oracle. A plataforma fornece uma API e um ambiente de tempo de execução para o desenvolvimento e execução de software corporativo, incluindo serviços de rede e da Web e outros aplicativos de rede de grande escala, multicamadas, escalonáveis, confiáveis ​​e seguros.

O ponto principal aqui é que Java EE é uma plataforma que fornece uma API, não alguma biblioteca concreta.

O que é necessário para o Java EE?

O escopo principal do Java EE são os aplicativos baseados em rede, ao contrário do Java SE orientado para o desenvolvimento de aplicativos desktop com suporte de rede simples. Essa é a principal diferença entre eles. Escalabilidade, mensagens, transações, suporte de banco de dados para cada aplicação ... a necessidade em tudo isso aumentou com a evolução da rede. É claro que muitas soluções prontas que o Java SE fornece são úteis para o desenvolvimento de rede, então o Java EE estende o Java SE.

Por que precisamos de servidores de aplicativos para executar nosso código?

Por que precisamos de sistemas operacionais? Porque há muito trabalho doloroso com o hardware que precisamos fazer para tornar a aplicação ainda mais simples. E sem o sistema operacional, você precisa fazer isso de novo e de novo. O sistema operacional simplificado é apenas um contêiner programático, que nos fornece um contexto global para executar nossos aplicativos.

E é isso que os servidores de aplicativos são. Eles nos permitem executar nossos aplicativos em seu contexto e nos fornecem muitas funcionalidades de alto nível que são necessárias para aplicativos de rede corporativa de alta carga. E não queremos escrever nossas próprias bicicletas para resolver esses problemas, queremos escrever um código que irá satisfazer nossas necessidades de negócios.

Outro exemplo aqui poderia ser JVM para Java.

Por que o Java EE não contém um servidor de aplicativo integrado?

Difícil dizer para mim. Acho que foi feito para ter mais flexibilidade. Java EE diz o que eles devem fazer, eles decidem como fazer.

Por que o JVM não inclui Java EE?

Porque se dirigiram a diferentes setores do mercado. Java EE tem um monte de funcionalidades que não são necessárias para desktops comuns.

Por que existem tantas ofertas Java EE?

Porque Java EE apenas descreve o comportamento. Todos podem implementá-lo.

O que se pode fazer com o Java EE que não pode ser feito com o Java SE?

Para conquistar a internet. É muito difícil fazer com os miniaplicativos e soquetes Java SE :)

O que se pode fazer com o Java SE que não pode ser feito com o Java EE?

Como mencionado acima, o Java EE estende o Java SE, portanto, com o Java EE você deve ser capaz de fazer tudo o que está disponível para o Java SE.

Quando um desenvolvedor decide que "precisa" do Java EE?

Quando precisam do poder do Java EE. Tudo o que foi mencionado acima.

Quando um desenvolvedor decide que não precisa do Java EE?

Quando eles escrevem um console comum ou aplicativo de desktop.

Por que as versões do Java SE e Java EE não são sincronizadas?

Java sempre teve problemas com suas tecnologias de nomenclatura e controle de versão. Portanto, esta situação não é uma exceção.

Java EE tem tudo a ver com o conceito de contêiner.
Container é um contexto de execução dentro do qual irá rodar sua aplicação e que fornece a este último um conjunto de serviços. Cada tipo de serviço é definido por uma especificação chamada JSR. Por exemplo, JSR 907, JTA (java transaction Api) que fornece uma maneira padrão de gerenciar transações distribuídas em diferentes recursos.
Geralmente, há muitas implementações diferentes para um determinado JSR, a implementação que você usará depende do provedor do contêiner, mas você realmente não se importa com isso, pois tem certeza de que o comportamento respeita o contrato predefinido: a API JSR.
Portanto, para aproveitar as vantagens do Java EE, você precisa executar seu aplicativo dentro de um contêiner. Os dois principais são o EJB e o contêiner de servlet, que estão presentes em qualquer servidor de aplicativos certificado para Java EE.

O objetivo de tudo isso é definir um ambiente de execução padrão para permitir empacotar seu aplicativo apenas com o essencial, id.est. seu negócio. Ele evita depender de um conjunto desconhecido e variado de bibliotecas de terceiros que você teria que empacotar e fornecer com seu aplicativo de outra forma, e que podem ser fontes de conflito com outros aplicativos no servidor. No Java EE, você sabe que todos os requisitos não funcionais padrão como segurança, transação, escalabilidade, invocação remota e muitos mais serão fornecidos pelo contêiner (fatorados para todos os aplicativos em execução dentro dele) e você só precisa basear seu trabalho nisso.