Spring: a história da vergonha do Java

Assuntos Gerais
#1

O problema do Spring é que ele foi mal projetado e isso foi provado ao longo dos anos. Uma boa tecnologia esconde os detalhes de implementação e expõe o suficiente para que o usuário possa focar no que precise fazer. É por isso que é possível dirigir um automóvel sem entender como as suas partes internas funcionam, por exemplo. Por isso usamos computadores sem necessariamente entender como projetar microchips.

Ao contrário do que alguns podem pensar, frameworks não apenas resolvem problemas, mas também introduzem alguns novos. Embora sempre tenha sido possível obter beans povoados de queries pela JDK padrão e DBUtils e cache seja um problema essencialmente de middleware, as pessoas decidiram usar o Hibernate para a camada de persistência. Problema resolvido? Não, pois agora além das configuraçãos extras nós temos que gerenciar as sessões dele. O Spring permite entre outras coisas, gerenciar tais sessões de forma automática. Problema resolvido? Não, pois agora além da configurações também temos um projeto que depende de 50 JARs. O Maven permite gerenciar essas dependências. Problema resolvido? Não, pois além das configurações agora ele também fará o famoso Maven downloads the internet.

O estado calamitoso do desenvolvimento Java era óbvio e ululante para qualquer pessoa de bom senso.

Pessoas como nós nem sempre conseguiam escapar de algum projeto tosco com Spring, e lidávamos da melhor maneira possível. Alguns procuravam alternativas, outros tentavam criar os seus próprios frameworks que seriam infinitamente mais inteligentes, até que…

O Rails surgiu!

Não sou fanboy de Ruby, e nem de nenhuma outra linguagem. Eu nem gosto de Ruby, mas o Rails foi essencial, para expor a fraude que é o desenvolvimento em Java. Não acho que seu criador tenha sido um gênio, ele apenas sabia o que muitos sabiam, que o desenvolvimento com Java e Spring e Hibernate é obscenamente horrível.

Assim Rails se tornou um ótimo exemplo de uma boa tecnologia, ou seja, que facilita a vida das pessoas.

O mundo dos desenvolvedores Java caiu! Rails, assim como Nêmesis aos reis, apequenou os “grandes” e suas turbas de seguidores Java. A verdade inegável brilhou e atodoou-os. O que era sabido de poucos se tornou fato para todos. Provou, sem a menor sombra de dúvida, o quão insano é trabalhar com Spring.

Por isso vemos o Java EE buscando simplificação, e coisas como o Grails surgindo,e várias linguagens na JVM oferecendo diversas facilidades. Mera luta pela sobrevivência. O mundo desses desenvolvedores Java acabou e outro está começando.

#2

#3

Cara, não conheço a fundo o historico do longino no GUJ e sei que tem muita gente que chama ele de troll.

Mas que esse post dele tem bastante fundamento, isso tem. Bastante!

#4

O que determina se um projeto é bom ou ruim é primeiramente a qualidade do seu arquiteto. E não o framework.

Um bom framework ajudará o bom arquiteto a expandir ainda mais o seu potencial. Porém, um framework não resolve o problema de um arquiteto ruim.

E o que tem de pseudo arquitetos por aí, não é brincadeira.

#5

[quote=YvGa]Cara, não conheço a fundo o historico do longino no GUJ e sei que tem muita gente que chama ele de troll.

Mas que esse post dele tem bastante fundamento, isso tem. Bastante![/quote]Ele tá falando isso vindo de outro post onde o pessoal já começou a ignorar o q ele fala. E o assunto lá era justamente spring… ^^
Entendo essa necessidade de se reafirmar ñ e de ficar causando polêmica.

#6

[quote=jakefrog][quote=YvGa]Cara, não conheço a fundo o historico do longino no GUJ e sei que tem muita gente que chama ele de troll.

Mas que esse post dele tem bastante fundamento, isso tem. Bastante![/quote]Ele tá falando isso vindo de outro post onde o pessoal já começou a ignorar o q ele fala. E o assunto lá era justamente spring… ^^
Entendo essa necessidade de se reafirmar ñ e de ficar causando polêmica.[/quote]

Tudo bem, e nem eu acho que o Spring é essa malignidade toda. Repare que o Grails utiliza o Spring e Hibernate por baixo dos panos para imitar o Rails.

O que eu acho que tem fundamento é a visao dele, sobre como as pessoas costumam dificultar ao extremo coisas simples só porque “viram” alguem fazendo daquele jeito. Eu vejo isso todo dia em todo lugar, coisas simples sendo dificultadas baseadas na “experiencia”.

Mas acho que o problema é muito mais do java do que do Spring na comparação com o Rails.

#7

[quote=YvGa]
Cara, não conheço a fundo o historico do longino no GUJ e sei que tem muita gente que chama ele de troll.

Mas que esse post dele tem bastante fundamento, isso tem. Bastante![/quote]

Sempre digo a verdade de forma bem articulada e lógica, mas isso parece incomodar alguns…

O problema do GUJ é panela. Existe uma panela aqui que quer monopolizar o discurso e manter certos interesses financeiros. O problema é que para cada atitude de bullying a imagem deles fica pior.

Assim como a sua sábia observação, existem inúmeras pessoas lendo isso que não postam por aqui regularmente e concordam.

O importante é sempre manter o nível e a classe, mesmo ante tal horda. Sejamos os melhores.

#8

Bom

Acredito que o Ruby ainda vai passar por muitos problemas que o Java já passou.
Hoje já existem alguns programadores Ruby que estão tendo uma preocupação com alguns aspectos como arquitetura do sistema coisa que antes isso era lenda no Ruby.

Mas não discordo sobre os problemas com Frameworks que o Longino citou anteriormente, pois com novos Frameworks surgem novos problemas. Acredito que cabe ao arquiteto colocar na balança e definir a melhor solução para o projeto.

Att,

#9

Quanto drama…

E que mundo seria esse, na sua visão?

#10

Estava eu aqui a abrir um tópico no guj justamente a respeito do spring e olha só o q vejo!! Não concordo com a opnião do autor do tópico.
Quando utilizamos um software de terceiro temos que nos adequar a tal software. Isso é fato. Se queremos algo que seja especificamente o q precisamos vamos lah e fazemos do jeito que queremos. Mas isso é complicado, mto complicado de fazer. Tome o exemplo do spring: além de ser um ótimo framework para injeção de dependencias e IOC também tem o MVC. Podemos nos conectar ao banco utilizando JDBC sem toda complexidade de utilizar JBDC puro, ou podemos utilizar JPA ou Hibernate alterando pouquissimas linhas de código (na verdade altera-se algumas configurações no xml e o seu DAO). Fica fácil implementar um sistema de controle de acesso, transações com o banco entre outras coisas q se pode fazer com o spring.
Imagine fazendo td isso do zero: qnd vc terminasse a infra o seu concorrente ja teria entregue o projeto.

A vantagem de frameworks é facilitar tdo aquilo q sabemos q será util. Tem o seu preço, mas realmente vale a pena!! Conforme mencionado por rogelgarcia não é o framework q determina o profissional!! Lembro de um colega meu qnd afirmava q orientação a objetos é uma grande besteira e q não serve pra nada. Como assim não serve pra nada?? Qntas aplicações rodam em java, C#, C++ e demais linguagens OO?? Qnts sistemas rodam com base no spring, hibernate ou qlq outro framework??

Embora o autor do tópico fale mto a repseito do spring os conceitos por ele apresentado caem mto bem em qualdquer outro framework… Mas e ae pq só o spring incomoda??

#11

Pessoal, por favor, o autor do tópico já é conhecido por suas opiniões duvidosas e que são sempre jogadas no fórum com o objetivo de criar flamewars, sendo assim, tomem cuidado para não alimentarem o troll tudo bem?

#12