[quote=asaudate]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:
[/quote]
Parcial ou não, penso que suas opiniões estão virando, cada dia mais, um lugar comum.
–
Rei
[quote=ReinaldoVale][quote=asaudate]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:
[/quote]
Parcial ou não, penso que suas opiniões estão virando, cada dia mais, um lugar comum.
–
Rei[/quote]
Trabalhei com as 2 tecnologias, de uns 4 anos para cá muito mais com Spring, apesar de em alguns momentos ter utilizado alguns produtos como RestEasy e RichFaces da JBoss.
Bil Burke é um dos monstros do mundo Java, com certeza muito do que ele disse no post realmente faz muito sentido. Só achei que a “porrada” que ele deu no Spring mostra o quanto estavam preocupados e incomodados com o sucesso do Framework.
O legado EJB 2 e App Servers “inchados e lentos” deixaram muita gente com pé atrás quanto a sua utlização. Quem aqui por muitas vezes não teve sucesso com Spring x Jetty rodando leve leve…
É o tal negócio, antes um rival por perto, te fazendo sempre buscar a excelência, do que sozinho. Ex: “Na cidade que moro, temos apenas uma opção para Telefonia e Internet. O que acontece? Preços abusivos, serviços horríveis”. Concorrência é tudo…
O Bill Burke poderia até ser o maior arquiteto da história da computação.
Porém, seu post é cheio de opiniões e não possui argumentos para validar suas afirmações.
Não é um post técnico, como mencionado pelo colega, e por isso não é uma notícia Java.
Mesmo considerando a importância do autor, o post foi digno de “blogueiro”.
Tem muito mais apelo passional e político do que técnico no artigo.
Uso Spring e continuarei usando. Ainda existe uma diferença arquitetural entre o Spring e o uso de CDI + Annotations que podem levar a preferência de arquitetos por uma ou outra tecnologia. O JEE não tornou o Spring supérfluo, apenas chegou no ponto onde o Spring já está. Vamos dizer que agora os dois são concorrentes em pé de igualdade.
Alguns pontos:
[list]CDI roda tranquilamente no Java SE com o Weld, por exemplo. Este tipo de uso será padronizado na versão 1.1[/list]
[list]Não usar versões novas de servidor de aplicação por medo de incompatibilidades, mas usar Spring por poder migrar a qualquer momento mostra apenas que a gestão do seu ambiente de produção foi muito mal definida, já que o objetivo era ter um stack estável e testado. E engraçado que é um argumento recorrente de quem usa Spring[/list]
[list]O CDI permite que seus metadados sejam definidos por qualquer mecanismo, uma vez que possui o conceito de extensions. O Seam Solder Config, por exemplo, permite, via xml, adicionar ou remover anotações de beans declarativamente ou criar instâncias configuradas de forma diferente de um mesmo bean. Qualquer outro mecanismo de configuração poderia ser implementado via extension. Configurações dinâmicas podem ser feitas combinando JMX com producers[/list]
[list]Quem acha que o Spring e o CDI estão em igualdade enquanto container DI precisa ler a spec do CDI direito. Apenas como exemplo trivial, comparem a facilidade de se fazer injeção de dependências com base no contexto em que a dependência aparece (ex: injetar um Logger com base na classe que contém a declaração dele) usando ambos[/list]
Sobre a morte do Spring eu duvido bastante. Pelo historico das versoes, o Spring vem dando soluções muito mais elegantes do que o EJB.
Foi assim na maior parte do tempo.
E sobre testes, o EJB ainda tem que evoluir um bocado, não acham? Ter features como CDI para justificar o uso de EJB é pouca vantagem.
O Spring sempre fez isso e muito bem. Outra vantagem são as abstrações que ele faz sobre a especificação, sempre tornando as coisas mais fáceis.
Além de ser muito mais leve.
Sobre testes, o SpringTest sempre foi fácil de usar e vou dizer, é uma complicação testar componentes do EJB.
Fico pensando que componentes ‘de servidor’ como EJB não são testaveis. rsrs
blackthorne,
O arquillian (http://www.jboss.org/arquillian) ajuda bastante em testes de EJB diretamente no container.
tudo bem LucianoM86, mas voce usa ele em todos os seus projetos com EJB?
Eu uso o spring-test sim, em todos.
Nos que tenho participado tenho usado sim, afinal preciso fazer os testes de alguma forma.
Assim como testo aplicações Spring também (com Spring-test ou diretamente), que aliás gosto bastante.
Eu acredito que o Spring não vai morrer…
O que acontece é que todos os frameworks e implentações evoluem.
O que está acontecendo com o JEE atualmente é a simplificação. Simplificação essa que absorveu muitas das idéias do Spring. JEE está evoluindo, melhorando.
O Spring também vai continuar evoluindo e simplificando.
Ambos vão evoluir buscando as melhores funcionalidades de cada um. É isso que motiva as mudanças.
Spring morrer difícil heim, na maioria dos projetos sérios que trabalhei era adotado o Spring.
O que eu vejo é que tentam fazer com que a comunidade engula JEE 6 com opiniões tendenciosas, na minha opinião o Spriing suportara as features do JAVA EE, Não gosto do JSF 2 vai fazer telas complexas de verdade, preterir JPA a Hibernate acho muito complicado, será que preciso mesmo usar EJB?
Integrações com legados?
Testes?
Produtividade?
Suporte a Rest transparente?
Suporte a Hibernate 4 ?
Suporte a tecnologias RIA?
[quote=Luca]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[/quote]
Normalmente não se tem acesso direto ao ambiente de produção. Toda alteração precisará ser testada e agendada para deploy em uma determinada janela. Por causa disso XML é um problema, pois apenas complica o desenvolvimento.
Sempre busquei evitar o uso de XML por causa disso, mas já fui obrigado a trabalhar em aplicações enormes (que usavam Spring) com arquivos XML de milhares de linhas. É um horror para dar manutenção, pois perde-se a verificação em tempo de compilação.
Spring sempre foi ruim, mesmo antes do advento dos Annotations.
Sobre Java EE vs. Spring só tenho a dizer: Graças a Deus. Agora sim poderemos trabalhar de uma forma sã.