Só para colocar mais lenha na fogueira.
Olá
[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]
Concordo 100%
O Spring ainda tem serventia em coisas que a ele foram acrescentadas. Concordo que a razão de existir o Spring tal como foi criado não existe mais. O Spring nasceu para facilitar coisas que hoje são fáceis.
Mas se for para usar o Seam ou JSF… me poupem…
Abraços
Luca Bastos
1 - Eu sou sempre a favor de usar a especificação padrão à ter que adicionar dependências externas, então, no caso da DI eu prefiro usar o J2EE puro a ter que adicionar o Spring no meu projeto, até porque a DI no J2EE 6 está muito simples de usar e fácil de entender.
2 - Como já falaram o Spring não é só DI
3 - Acredito que o J2EE vai está sempre atrás dos frameworks do mercado. O Spring já tinha DI bem antes do J2EE 6 ser lançado, então o JCP criou alguma JSR para atender esse requisito que ficou em discussão durante um tempo e enfim, foi implementado. Provavelmente será assim com outras boas tecnologias já existentes em frameworks externos a especificação padrão.
Então, minha conclusão é que, o J2EE 6 com certeza enterra o Spring em algumas funcionalidades, como é o caso da injeção de dependência, mas, existem outros módulos do Spring que o J2EE ainda não tem e portanto, não vai enterrar.
Também sempre usei Spring, mesmo porque na época dos EJB 2.x era inviável usar J2EE.
Mas com a chegada do JEE5 e principalmente do JEE6, as coisas ficaram muito melhor e a necessidade de se usar Spring (principalmente seu módulo core de DI/IOC) parece não existir mais.
Mas como já foi dito acima, o Spring é mais do que simplesmente DI/IOC/Aspectos.
ele não só tem grande importância pela responsabilidade dele em um dos servidores mais utilizados no mercado como também por ter escrito o livro mais usado para uma das certificações mais respeitadas desse universo java…
mas eu diria que o spring “como é hoje” não vai sobreviver no que se refere a projetos novos, sobrando legado… mas acredito também que novas versões virão… tem a história do container leve, o que é uma vantagem. Eu tenho a impressão que vai ter bastante gente que vai continuar usando spring com frameworks MVC que são baseados em actions… só um palpite… (eu mesmo gostei de CDI, JSF 2, do pacote em si eu gostei bastante, mas eu ainda acredito que o spring ainda vai sobreviver como concorrente).
Bom, li o artigo e discordo de alguns pontos.
“Spring Always Depended on Java EE” - discordo devido a minha própria experiência profissional com Spring. Sim, há vários wrappers no Spring que envolvem componentes do Java EE como JMS, JPA, Transações, etc, mas é importante lembrar um ponto aqui: estes wrappers nunca foram o core do Spring ou a razão de adoção principal do framework, mas sim o seu excelente container de injeção de dependências E o fato de podermos usar AOP sem muita dificuldade (AOP ainda não está no Java EE até aonde pude observar com tamanha facilidade quanto a que encontramos no Spring).
Na realidade, eu usava o Spring sem Java EE desenvolvendo aplicações desktop. Como meu cliente possuia inúmeros ambientes de deploy, o Spring caia como uma luva, porque bastava eu alterar o xml de configuração de beans, sem a necessidade de recompilação e voilá, configuração nova prontinha para o “ambiente hostil”. Até tentei simplificar o Spring em um experimento chamado miocc (http://miocc.itexto.com.br), mas no final das contas, me rendi ao container do Spring que era anos luz superior e sempre muito, MUITO leve. Sendo assim, discordo: o foco do Spring é o seu container DI E AOP, que ainda são excelentes E, mais interessante, oferecem uma flexibilidade de opções de configuração (XML, Anotações ou Java) que o Java EE ainda não oferece.
“Annotations were a game changer” - Se for pra pensar numa evolução do Java que mudou tudo, sem dúvida foi a introdução das anotações. Com elas se tornou possível incluir metadados nas nossas classes Java e uma gama monstro de soluções surgiu via reflexão. Infelizmente, dentre as novidades que vieram com as anotações foram os “xiitas anti-XML”. Enquanto há documentos XML monstruosos cuja manutenção é um inferno, muitos vendam os olhos para o fato de que também há monstruosidades usando anotações e com um “probleminha” a mais: ao contrário do XML, você não consegue externalizar anotações sem a necessidade de recompilação. No meu caso, em que era feito desenvolvimento de um produto para diversos ambientes, adivinha quem ganhava: anotações ou XML? XML NA VEIA.
(Outro ponto importante em prol do XML. No ambiente de produção, o analista de sistemas não pode contar com a recompilação do sistema, mas sim com alteração de configurações externalizáveis. Imaginem como seria um ambiente sem estes arquivos.)
“CDI closed API hole” - De novo discordo porque no caso do CDI, este está muito mais focado em aplicações Java EE do que “não EE”. Além disto, é interessante observar alguns fatos: o primeiro deles é que CDI é uma abstração em cima do conceito de injeção de dependências, assim como o JPA para ORM. Consequentemente, temos aqui o menor denominador comum. Sim, o Weld é lindo e tal, mas baseia-se em dois pontos que não são a última bolacha do pacote: auto wiring e anotações apenas. Quem já trabalhou com auto wiring sabe dos problemas que costumam acontecer quando o sistema cresce, e com relação ao uso exclusivo de anotações, como mencionei acima, há o problema de não serem fácilmente externalizáveis. (tenho 25 páginas de argumentação a este respeito http://www.itexto.net/devkico/?p=859 
)
“App Servers got their act together” - as pessoas não usavam Spring por causa do tempo de boot dos servidores, mas porque o modelo de desenvolvimento era superior por ser baseado em POJOs ao invés da implementação daquelas interfaces melequentas. Sim, havia o ganho do tempo de boot, é claro, mas convém lembrar que mesmo hoje, com servidores que startam em segundos, desenvolver e testar contra estes servidores, versus desenvolver e testar versus POJOs não é só mais eficiente na questão tempo, mas performance também.
“Arquillian made a mock of mocks” - ai há um problema na argumentação sério também. Bill Burke diz que um dos fatores da “derrota” do Spring é que um outro projeto, fora da especificação Java EE surgiu??? E outra: quem aqui adotou o Spring ao invés da especificação padrão Java EE por causa das suas funcionalidades de teste que atire a primeira pedra. Nunca encontrei ninguém.
Bom gente…o carro chefe do spring foi sempre fazer o “ligthware” container sempre justificando o uso no lugar dos container pesados JEE.
E para quem já viu…o “web profile” realmente é um completo “ligthware” que se encaixa da mesma forma…
Mas o spring tem varios outros produtos e motivações para existir…é leque de coisas bem extenso.
Acho que ele sofrer uma queda de preferencia por causa do web profile…mas morrer eu acredito que não.
Olá
[quote=kicolobo]
“Annotations were a game changer” - Se for pra pensar numa evolução do Java que mudou tudo, sem dúvida foi a introdução das anotações. Com elas se tornou possível incluir metadados nas nossas classes Java e uma gama monstro de soluções surgiu via reflexão. Infelizmente, dentre as novidades que vieram com as anotações foram os “xiitas anti-XML”. Enquanto há documentos XML monstruosos cuja manutenção é um inferno, muitos vendam os olhos para o fato de que também há monstruosidades usando anotações e com um “probleminha” a mais: ao contrário do XML, você não consegue externalizar anotações sem a necessidade de recompilação. No meu caso, em que era feito desenvolvimento de um produto para diversos ambientes, adivinha quem ganhava: anotações ou XML? XML NA VEIA. [/quote]
Sempre lembrei disso quando alguém tentava provar de que configuração prográmatica só tem vantagens. Já passei por caso bem semelhante ao seu. A gente mudava coisas sem fazer novo deploy (e sem JMX). Basta fazer o sistema reler o arquivo quando percebe mudança.
Resumindo… não há bala de prata. Mas infelizmente tem framework que não aceita configuração se não for dentro do código.
Abraços
Luca Bastos
Existe um outro ponto que ainda justifica o Spring como solução “light weight”. As pessoas costumam achar que “light weight” é igual a “consumir menos recursos computacionais”.
Não é nada disto. Um framework “light weight” é aquele que é mínimamente intrusivo, ou seja, que não requer que você altere o código fonte de suas classes para que funcionem com ele.
No caso do Java EE, não temos um framework tão “leve” assim, porque o simples fato de você incluir uma anotação em uma classe já adiciona acoplamento (mesmo que apenas estático) entre esta e o framework em questão. No caso do Spring, usando XML você pode reaproveitar o seu código legado sem precisar “tocar” no mesmo. Sendo assim, pra manter código legado (e código legado não quer dizer código ruim, mas aquele que simplesmente FUNCIONA), Spring ainda é uma das soluções mais “leves” que existem hoje.
Acho que falta um tom de imparcialidade aí. Até porque, não sei se todos aqui do fórum sabem, mas o Bill Burke é muito parcial nesse ponto por diversos motivos:
- Ele esteve bastante envolvido no desenvolvimento do mecanismo de EJB como um todo (não me lembro até que ponto, só lembro que foi bastante!)
- Ele é bastante passional quando se trata do Rod Johnson (como visto em parágrafos como:
Além disso, tem um post daqui que mostra a ‘guerrinha’ entre os dois: http://www.guj.com.br/java/82044-bill-burke-ejb-x-rod-johnson-spring
- Ele trabalha na JBoss, que tem um dos AS’s mais famosos e, obviamente, depende do sucesso da especificação padrão de JavaEE.
- A mesma JBoss desenvolveu o Seam, que por sua vez, conteve as primeiras versões de injeção de dependências em JavaEE como conhecidas hoje.
Ou seja… torço para ver a resposta do Rod Johnson logo. Mas também, torço para que isso não se torne simplesmente uma guerrinha de egos (como, aliás, já houve entre os dois antes).
Acho a discussão bastante saudável mas não gosto da postura do Bill e algumas respostas do tipo "Good luck with that"
Queria ver mais argumentos técnicos do que este tipo de resposta… Essa guerrinha de egos não leva a nada, é patético.
Eu uso muito Spring porque o container que uso é bem lento em acompanhar as especificações e por restrições do negócio utilizar containers recem saidos do forno é um risco muito grande… Claro que gostaria de usar a versão mais nova do container assim que liberada mas não dá pra pesar só o fator tecnológico em uma base muita grande de aplicações instaladas… Com o Spring consigo moldar as aplicações para técnicas recentes sem ter que atualizar meu container e assim na hora que puder usar o que o jee me fornece como padrão o trabalho de migração é bem menos traumático.
até porque, vendo esse Bill Burke, podemos ver que toda a empresa tem o seu Steve Balmer que merece
[quote]Na realidade, eu usava o Spring sem Java EE desenvolvendo aplicações desktop. Como meu cliente possuia inúmeros ambientes de deploy, o Spring caia como uma luva, porque bastava eu alterar o xml de configuração de beans, sem a necessidade de recompilação e voilá, configuração nova prontinha para o “ambiente hostil”.
“Annotations were a game changer” - Se for pra pensar numa evolução do Java que mudou tudo, sem dúvida foi a introdução das anotações. Com elas se tornou possível incluir metadados nas nossas classes Java e uma gama monstro de soluções surgiu via reflexão. Infelizmente, dentre as novidades que vieram com as anotações foram os “xiitas anti-XML”. Enquanto há documentos XML monstruosos cuja manutenção é um inferno, muitos vendam os olhos para o fato de que também há monstruosidades usando anotações e com um “probleminha” a mais: ao contrário do XML, você não consegue externalizar anotações sem a necessidade de recompilação. No meu caso, em que era feito desenvolvimento de um produto para diversos ambientes, adivinha quem ganhava: anotações ou XML? XML NA VEIA. [/quote]
Não sei se entendi o que você disse de maneira correta, mas felizmente, no cenário JEE6 a parte de diversas regras de negocio para ambientes diferentes de deploy é uma tarefa extremamente simples e configurável por XML. Não que eu seja contra o spring, acho uma ferramenta extramente válida, assim como o CDI do JEE… mas nesse ponto… não consigo encontrar uma diferença que me faria optar pelo Spring.
Quanto diferente eram esses ambientes ? se eram apenas application servers tem algo errado não ?
Quanto diferente eram esses ambientes ? se eram apenas application servers tem algo errado não ?
[/quote]
Cara, eram extremos. No caso, precisavamos reaproveitar a nossa lógica de negócio não só entre servidores de aplicação diferentes, mas em versões do sistema que eram desktop. (yeap, estas coisas acontecem)
[quote=FernandoFranzini]Bom gente…o carro chefe do spring foi sempre fazer o “ligthware” container sempre justificando o uso no lugar dos container pesados JEE.
E para quem já viu…o “web profile” realmente é um completo “ligthware” que se encaixa da mesma forma…
Mas o spring tem varios outros produtos e motivações para existir…é leque de coisas bem extenso.
Acho que ele sofrer uma queda de preferencia por causa do web profile…mas morrer eu acredito que não.
[/quote]
Concordo. Os “Web Profile” sao realmente lightweight. Passei a usar o Java EE 6 com CDI, EJB3.1, JPA e etc…e ate hoje nao senti mais falta do Spring.
Acho que o Bill falou uma das coisas mais importantes. Mesmo com a demora da saida do Java 7, o Java e as especificações evoluiram MUITO, ao contrario do Spring. Para aqueles que ja viram ate o roadmap do java EE 7, vai encontrar ideias promisoras.
Tambem nao acho que vai morrer, afinal tem sempre alguem que continua usando.
E isso é assim mesmo, vale lembrar que o hibernate ja foi um dia unico e exclusivo. Hoje JPA 2 virou referencia e Hibernate apenas uma implementação. Spring é a mesma coisa.
Cara, mas é só anotar suas classes com @Alternative, implementar a mesma interface e voila… Depois é só mudar no beans.xml e mudar a regra de negocio em tempo de execução…
Cara, mas é só anotar suas classes com @Alternative, implementar a mesma interface e voila… Depois é só mudar no beans.xml e mudar a regra de negocio em tempo de execução…[/quote]
Yeap, hoje. Mas naquela época não tinhamos isto.
Além do que, eram ambientes muito variados, por exemplo: tinham implantações que só podiam executar no notebook de um sujeito sem conexão a rede (monstruosidades deste tipo).
No caso do CDI, temos esta possibilidade hoje, mas mesmo assim, quando você vai ler a especificação, percebe que é um negócio muito preso ao servidor de aplicações ainda (eu sei que você pode usar o Weld fora de um servidor).
Mas eu penso que é até “natural” esse tipo de atitude do Bill Burke pelo seu envolvimento com o EJB e, como disse o colega asaudate, ele é da Jboss, que depende diretamente
da adoção e do sucesso das especificações. Um outro exemplo é a própria documentação do Seam (que é um framework que gosto muito), fica claro que é um framework que “encoraja” e “incentiva” o uso de EJBs. Apesar disso, achei um pouco triste esse texto, pois me pareceu que a postura do Burke foi algo como “agora o JEE está foda, vou fazer um post descascando aquela merda do Spring, harn harn harn”. Gosto muito do Spring, é uma ferramenta que a meu ver agrega muito valor ao Java. Particularmente, não vejo o que a comunidade teria a ganhar com a “morte” do Spring; Bill Burke, ao contrário, parece estar comemorando. Lamentável.
Sobre a adoção das especificações, eu penso que é uma coisa boa para o Java, de qualquer forma. Quando eu programava em C#, que Deus me perdoe hehe, eu aprendia como mexer com o .NET Framework e a API disponível, e eu sabia que aquele era o jeito de se fazer as coisas com C#. Uma das coisas que me atraiu pro Java foi a grande gama de frameworks que temos disponíveis, mas penso que isso eleva a curva de aprendizado da plataforma, no sentido de que se alguém novato posta aqui no GUJ “como eu faço isso em Java?”, as respostas provavelmente serão “no framework X é assim, no framework Y é assado”. Apesar das várias opções de frameworks que temos disponíveis acredito que há esse outro lado, onde essa mesma variedade de escolha pode “atrapalhar”. Nesse ponto de vista acho que as padronizações e especs são importantes sim.
Fora que dá para usar Spring no Java SE, há de se apontar que só muito recentemente que os todos principais application servers enterprise, Oracle WebLogic 12c, IBM WebSphere 8, JBoss AS 7.1 e Apache Geronimo 3.0-beta-1 foram certificados em Java EE 6 Full Profile, 2 anos após a aprovação da especificação do Java EE 6 (sob vários protestos e a saída da Apache da JCP).
Nesse meio tempo, e também das vezes passadas com as outras versões, o Spring estava lá segurando muito bem as pontas.