Gavin King [1], o pai do Hibernate, recomendou que os desenvolvedores atualizassem para a plataforma Java EE 6 e apontou que a relutância atual em atualizar é na verdade infundada.
Após o lançamento do Java EE 6, vi muita resistência em atualizar para a nova plataforma. A maioria dessas objeções é levantada por usuários do Tomcat/Jetty e de alguns frameworks de código aberto (como Hibernate e Spring).
É claro que há muitos benefícios em escolher tecnologia de código aberto não padronizada. Além disso, no EE 6, você pode usar as estruturas de código aberto de seu interesse. O Servlet 3 e o CDI podem integrar perfeitamente estruturas de terceiros. Portanto, não há razão para não usar o EE 6. Mesmo assim, vi alguém dizer:
Atualizar para o EE Application Server é difícil
Esta parece ser uma questão política para a organização específica, e não uma questão técnica real. É claro que atualizar um servidor como GlassFish ou JBoss é uma tarefa muito trivial. (Atualizar estruturas de terceiros é ainda mais doloroso.) Algumas organizações têm um processo muito pesado para atualizar servidores, mas não tanto para atualizar as estruturas em execução nos servidores. Portanto, é mais fácil para a equipe de desenvolvimento atualizar estruturas de terceiros.
Acho que desenvolver um processo melhor e mais convincente é o mais importante, em vez de abandonar o Java EE. Existem muitos riscos associados à execução do seu aplicativo em uma plataforma de servidor antiga e desatualizada, e o processo não deve encorajar tais práticas.
Mas do ponto de vista prático, quase todo mundo está planejando atualizar para o Servlet 3 em um futuro próximo. Esteja você usando Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle ou WebSphere, isso significa uma atualização do servidor. Esta é uma ótima oportunidade para atualizar para o EE 6 Web Profile, época de ouro.
O servidor de aplicativos EE é muito grande
A objeção é que o EE Server contém muitos recursos que não estão (atualmente) disponíveis. Os argumentos dos oponentes geralmente envolvem a discussão do tamanho do pacote jar e do espaço em disco ocupado pelo mecanismo Servlet + estrutura de terceiros e pelo servidor de aplicativos EE. Na verdade, este argumento é problemático:
O uso do disco e o espaço em disco discutidos são realmente triviais quando medidos em $, e o pacote war do aplicativo é muito mais importante do que o tamanho do pacote de instalação do servidor. Na verdade, o servidor contém muitas funções para minimizar o tamanho do war.
Além disso, acho que o mais convincente é que o Java EE 6 Web Profile não é nada grande. Assim que os servidores Web Profile certificados estiverem no mercado, poderemos encontrar um equilíbrio entre grandes servidores de aplicativos EE e pequenos contêineres de Servlet.
J2EE e EJB2 ruins!
Com o processo de padronização do JCP, esse problema realmente não existe mais:
1. Já se passaram 8 anos desde que o EJB2 apareceu! Ainda é sua melhor escolha?
2. Boas especificações foram mescladas por meio da padronização contínua do JCP, e algumas delas podem ser usadas com grande certeza. No entanto, o JCP não tem 100% de sucesso na padronização.
3. Todos que trabalham na plataforma EE 6 odeiam EJB2 e J2EE. É por isso que as pessoas aderem constantemente ao JCP para ajudar a resolver esses problemas. Por exemplo, o fundador do Hibernate e autor deste artigo. Você realmente quer ensinar a ele uma lição sobre EJB2? :-)
4. Quase todas as pessoas que trabalham em Entity Beans estão aposentadas agora!
Na verdade, o Java EE 6 Web Profile é suficiente. Se você não experimentar o Java EE 6, não poderá realmente sentir os benefícios do EE6 para o desenvolvimento.
A portabilidade do servidor de aplicativos é um mistério!
Realmente? Vemos muitas pessoas dividindo seus aplicativos e implantando-os em diferentes servidores de aplicativos? Ah, eu vi que isso significa portabilidade de alteração 0 de aplicativos 100% perfeita, um ideal platônico de portabilidade. Entendo a fraqueza pela verdade absoluta e pelos ideais platônicos, mas vejamos primeiro os exemplos.
Aqui está uma visão muito típica de um problema de portabilidade:
9% do código, 85% dos metadados externos são totalmente compatíveis em diferentes plataformas de servidor e os 1% e 15% restantes podem ser divididos adequadamente
0% de código, 80% de metadados externos vinculados à arquitetura de contêiner não padrão e de fornecedor único
Enquanto dividia esses pontos, de repente quis mudar o tópico desta seção de que a portabilidade do servidor de aplicativos é muito misteriosa para não me importar nem um pouco com a portabilidade do contêiner. A ideia de mudança de tema confirma que o problema da portabilidade de servidores é real e que será muito útil para muitas organizações.
Sempre quis ver análises reais do EE 6 de mantenedores técnicos que não são do EE 6. Alguns dos argumentos mencionados acima não vêm do mundo real, por isso é difícil desencadear discussões sobre questões técnicas reais de desenvolvimento de aplicações na plataforma EE. A última ronda de especificações do JCP parece ter abandonado o campo anti-EE (temporariamente?), mas carece de apoio factual para o sucesso.
Nota do editor:
[1] Gavin King: Fundador do Hibernate, membro do Comitê de Especialistas EJB3, um dos principais membros do JBoss, líder do framework Seam, líder da especificação JSR-299 (CDI) e autor do livro "Hibernate in Action" .
Fonte: Você deve atualizar para Java EE 6