Java EE versus Spring: a visão de Bill Burke

Assuntos Gerais Notícias
#1

Bill Burke anuncia uma futura morte do Spring. Bill Burke trabalha no grupo JBoss e sempre teve suas opiniões polêmcias:

Terminando com “For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.”, Burke exprime diversos pontos.

Alguns fazem bastante sentido. O Java EE foi em direção a simplificação, quebrou muitas especificações e agora podemos utilizá-las sem precisar de um container full, colocando apenas o que é realmente necessário. O Spring parece ter indo para um lado um pouco mais complexo.

O que você está utilizando e o que você utilizará em seus próximos projetos Java? O CDI e as anotações realmente tornaram o Spring supérfluo?

#2

[quote=Paulo Silveira]Bill Burke anuncia uma futura morte do Spring. Bill Burke trabalha no grupo JBoss e sempre teve suas opiniões polêmcias:

Terminando com “For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.”, Burke exprime diversos pontos.

Alguns fazem bastante sentido. O Java EE foi em direção a simplificação, quebrou muitas especificações e agora podemos utilizá-las sem precisar de um container full, colocando apenas o que é realmente necessário. O Spring parece ter indo para um lado um pouco mais complexo.

O que você está utilizando e o que você utilizará em seus próximos projetos Java? O CDI e as anotações realmente tornaram o Spring supérfluo?[/quote]

Eu pulei direto do Struts pro Seam

E agora vou de Seam3 em um novo projeto.

Na minha visão o spring hoje é sim tecnologia do passado.

#3

Nos meus ultimos projetos acredito que em todos eu usei Spring. Nao apenas seu container de IoC, mas também pelo controle de transacoes, MVC, e integracao facil com outros frameworks. Atualmente estou terminando um projeto 100% JEE e gostei. Nao perde em nada para o Spring e nao senti falta ainda do mesmo.

#4

Se o JavaEE é realmente o futuro do Java, então quem irá morrer será o próprio Java.

#5

Não considero Spring morto nem um concorrente direto do Java EE, embora compartilhem muitas funcionalidades. A proposta do Spring é integrar diferentes frameworks em diferentes camadas, sendo a injeção de dependências apenas uma parte da história. Eles checam o que está sendo bem aceito no mercado e criam o gluecode com os frameworks das camadas de cima ou de baixo. Um exemplo é a integração que foi feita com o flex, que permite reaproveitar anotações das camadas de serviço ao invés de fazer configurações manuais.

#6

Meu velho, me desculpe ou eu não entendi o que você quis dizer ou esse negócio que você fumou ta estragado, framework vem e vai, a tecnologia base fica.
O Struts 1 não morreu, quanto mais o spring, pode diminuir sua utilização pelos motivos padões (IOC, controle transacional para containers mais simples) no entanto o spring não e só isso.

Isso só foi mais água na minha cerveja de sábado a noite.

#7

Respeito todas as opiniões…por mais polêmicas que sejam. Gosto muito de trabalhar com Spring apesar de ser implementação. Acho sim…que cada vez mais as especificações simplificarão a nossa vida no que se refere a desenvolvimento, mas também acredito na alta eficiência. Trabalhar com Spring, principalmente no contexto de iOc ainda, na minha opinião continua sendo predominante na opinião da maioria.

#8

Também estou trabalhando em um projeto 100% JavaEE 6 com EJB 3.1, CDI, JPA 2 com Hibernate, JBoss 7 e etc e estou gostando muito. Sempre tinha trabalhado com Spring e não senti nenhuma falta dele até agora. Acho que morrer não vai pois em alguns casos como o de Flex citado, ele se integra muito bem, apesar de que o EJB não fica muito atrás, bastando ao invés de anotar a classe de Serviço, adicioná-la no remoting.config. Pra mim a vantagem do Spring em relação ao JavaEE era simplificar o desenvolvimento, o que hoje em dia não é tão necessário.

#9

EJB deve ver forte entaum? pq pennso em implementar o Spring mas dps desse post tenho duvidas…

#10

Meu velho, me desculpe ou eu não entendi o que você quis dizer ou esse negócio que você fumou ta estragado, framework vem e vai, a tecnologia base fica.
O Struts 1 não morreu, quanto mais o spring, pode diminuir sua utilização pelos motivos padões (IOC, controle transacional para containers mais simples) no entanto o spring não e só isso.

Isso só foi mais água na minha cerveja de sábado a noite.[/quote]

O que é mesmo triste é quando a opinião de um blogueiro sobre um assunto é considero notícia na comunidade Java.

#11

Muita gente não conhece o CDI e não sabe do que ele capaz. Enquanto solução de DI, é muito superior ao Spring.

A questão é que o Spring não é apenas DI e tem muitas APIs baseadas nele - e, diferentemente do que se vende, amarradas com ele. Se fosse feito um esforço para torná-las independentes do Spring, realmente o Java EE 6 enterraria o Spring.

Trolls em 3, 2… :slight_smile:

#12

[quote=mister__m]Muita gente não conhece o CDI e não sabe do que ele capaz. Enquanto solução de DI, é muito superior ao Spring.

A questão é que o Spring não é apenas DI e tem muitas APIs baseadas nele - e, diferentemente do que se vende, amarradas com ele. Se fosse feito um esforço para torná-las independentes do Spring, realmente o Java EE 6 enterraria o Spring.

Trolls em 3, 2… :slight_smile: [/quote]

Eu concordo.

Eu penso que existem tecnologias que são referências e ficam como base para muitos e muitos sistemas, como foi o struts e claro o legado desses sistemas vai levar a muita gente ainda trabalhar com esse framework

Assim como Spring tem muitos e muitos sistemas, mas ficou no passado.

Os frameworks atuais aprenderam com os frames do passado e ficaram melhores, e assim vamos evoluindo.

Um exemplo pode ser o log4j e o slf4j.

Sistemas de ponta, ou de inovação irão usar novos frameworks até para testar se eles dão realmente conta e servirem como benchmark

Então naturalmente as tecnologias vão se sobrepondo.

#13

Bill Burke blogueiro ?

Acredito que antes de categorizar o mesmo como um simples blogueiro, uma “googleada” em seu nome lhe traria alguns resultados que ilustrariam a importancia de pessoas como ele no cenário JAVA atual:

http://www.java.net/pub/au/10

Bill Burke is Chief Architect of JBossGroup, LLC. He is co-author of
O’Reilly’s “JBoss 3.0 Workbook” (
http://www.oreilly.com/catalog/entjbeans3/workbooks/index.html ) and
numerous other articles at www.onjava.com. His career has followed the
evolutionary path of distribued computing. He implemented parts of DCE
while at the parent company of Open Environment Corporation, CORBA as a
core-developer of Iona’s Orbix 2000 product, and J2EE as the lead of JBoss
4.0. Currently he is expanding JBoss to apply Aspect Oriented Programming
to distributed infrastructures.

Java Champion

Além disso, hoje ele é o principal responsável pelo RestEasy , umas das principais implementações da especificação REST para Java.

Por fim, vale ressaltar que como muito bem citado pelo Paulo Silveira, Bill Burke é uma pessoa de opiniões controversas e de personalidade forte, logo, o mais interessante sobre esse tópico/notícia não seria apenas aceitar isso como verdade única, mas sim, fomentar uma discussão baseada em argumentos técnicos sobre o tema proposto. Acho que todos ganhariam muito mais se escolhessemos esse caminho em nossas argumentações e opiniões.

[quote=mister__m]Muita gente não conhece o CDI e não sabe do que ele capaz. Enquanto solução de DI, é muito superior ao Spring.

A questão é que o Spring não é apenas DI e tem muitas APIs baseadas nele - e, diferentemente do que se vende, amarradas com ele. Se fosse feito um esforço para torná-las independentes do Spring, realmente o Java EE 6 enterraria o Spring.[/quote]

Acredito que o pessoal da Spring Source tenha tentado fazer isso separando o “Spring” em vários pequenos módulos (Spring Core, transactions, flow, etc…) mas na minha opinião esses módulos ainda são muito interdependentes, logo, não sei se valeu a pena em quebrar em tantos pequenos componentes.

Acho que grande vantagem do JBoss SEAM sobre o Spring além do suporte realmente a CDI, é que o mesmo agora se tornou parte da especificação, logo, de certa forma isso força a outros grandes players como IBM, Oracle, etc… a suportar essas features, ou seja, o Spring por acabaria ficando “sozinho” para brigar com esses caras.

Não conheço muito bem o JBoss Seam mas trabalhei bastante com Spring, gostei muito, porém acredito que o frameworks que suportem CDI tenham mais vantagens, recursos e facilidades a oferecer para propagação e gerenciamento de contextos do que propriamente Spring com seu “simples” DI.

#14

[quote=Paulo Silveira]Bill Burke anuncia uma futura morte do Spring. Bill Burke trabalha no grupo JBoss e sempre teve suas opiniões polêmcias:

Terminando com “For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.”, Burke exprime diversos pontos.

Alguns fazem bastante sentido. O Java EE foi em direção a simplificação, quebrou muitas especificações e agora podemos utilizá-las sem precisar de um container full, colocando apenas o que é realmente necessário. O Spring parece ter indo para um lado um pouco mais complexo.

O que você está utilizando e o que você utilizará em seus próximos projetos Java? O CDI e as anotações realmente tornaram o Spring supérfluo?[/quote]

Esse Bill Burke anuncio bobagem!

#15

Posso ter visto poucos projetos utilizando Spring mas a grande maioria só o utilizava por conta de DI, ai fica o ponto, vale realmente a pena ter todas aquelas dependencias so por conta de DI/IoC ? sera que o pessoal ta realmente utilizando essa ferramenta de forma adequada ou o que ta rolando mesmo é muito modismo e arquitetura de caixinha ?

Um monte de CRUDS com implementações unicas e expecificas, ou em alguns casos até “generica” sendo injetada como implementação. Estamos fazendo isso de forma correta ?

#16

[quote=benflodin]Posso ter visto poucos projetos utilizando Spring mas a grande maioria só o utilizava por conta de DI, ai fica o ponto, vale realmente a pena ter todas aquelas dependencias so por conta de DI/IoC ? sera que o pessoal ta realmente utilizando essa ferramenta de forma adequada ou o que ta rolando mesmo é muito modismo e arquitetura de caixinha ?

Um monte de CRUDS com implementações unicas e expecificas, ou em alguns casos até “generica” sendo injetada como implementação. Estamos fazendo isso de forma correta ?[/quote]
Com certeza, o que acontece é a modinha! Também acho que o que interessa do Spring é o IoC o resto pode ser resolvido com padrões de projeto.

#17

Me Perdoem a ignorância, mas pq esse título Java EE versus Spring? Java EE é uma plataforma para servidores e Spring um framework o que o faz competir um contra o outro? :shock:

#18

Bem, já te deram a resposta não é? O Bill Burke, para quem conhece bem Java EE e está por dentro do desenvolvimento dos servidores, dispensa apresentações. É um dos grandes nomes do Java.

#19

Muitos dos objetivos dos dois se cruzaram há algum tempo: facilitar o desenvolvimento de aplicações “enterprise”

#20

Eu sempre fui spring fanboy, mas honestamente, não tenho utilizado as últimas versões do JavaEE e pra ser sincero nem o Java 7. Então hoje em dia estou um pouco enferrujado.

Sinceramente, estou muito interessado em ver todas as novas features do Java mas antes disso, alguém poderia responder as seguintes perguntas pra mim por favor?

1- A inversão de controle é somente aquelas injeções de dependência utilizadas no EJB3 com @Resource e afins?
2- Como fica a questão de IoC em aplicações stand alone?
3- Sabemos que JBoss Seam é tri legal, desde a primeira versão. Entretanto, hoje em dia, as aplicações Seam continuam mega pesadas? Digo isso porque uma coisa é ter uma plataforma bonita e mega integrada com tudo, outra coisa é você alterar uma classe, dar publish e esperar 1 minuto pro servidor subir.
4- Como fica a questão de AOP estático no Java/JavaEE?
5- É complicado dizermos que Spring irá morrer porque, na minha opinião, as pessoas “tem uma visão muito superficial” do Spring. Qual parte do Spring que o JEE irá suprir?
6- Uma das coisas que eu mais gosto do Spring é a facilidade de criação de testes. Atualmente, como estão essas questões no JavaEE?
7- Existe algo hoje que substitua o Spring Security?

Uma constatação: O Spring está virando uma mega plataforma gigante, com N módulos, Cloud-computing etc. Parece que o grau de complexidade está ficando bastante alto e, pelos comentários dos users, parece que o JEE está indo exatamente para o lado contrário: simplicidade e “powerful”. Isso é ótimo! Parece que a Oracle e a comunidade estão andando bastante juntas para a evolução da plataforma. Gostei muito da notícia.