Bill Burke (EJB) X Rod Johnson (Spring)

Ola Felipe

Primeiramente parabens pelo excelente post-noticia.

O Rod Johnson sabe que ejb3 esta ganhando muita forca e comendo um pouco do mercado do spring. Se ele nao soubesse disso, nao teria entrado pra spec do Java EE 6. Quando ele diz que ejb3 ainda é um elefante branco, parece ate que ele nao estudou a tecnologia direito.

Sobre a quantidade de empregos, esta nao é a realidade do Brasil. Sem duvida o que a gente mais ve hoje em dia é JSF e EJB3.

Creio que JEE 5/EJB 3 está bem nivelado com Springframework a ponto da escolha de um ou outro depender mais de gosto pessoal do que vantagens técnicas em si.

Eu respeito Rod Johnson, ele escreveu um dos melhores livros de J2EE que existe e criou Spring utilizando sua experiencia e instatisfação com o Status Quo que existia, a ponto de um projeto open-source rivalizar uma especificação feita pelos maiores players do mercado.

Pena que eu acho que ele se perdeu um pouco ao longo do caminho, a idéia inicial era tornar J2EE mais simples, e isso ele o fez, porém agora o framework já quer ser uma solução completa, querendo criar uma silver bullet, e creio que e ele não tem força para isso.

Já JEE 5 não é perfeita, mas percebeu que o mercado queria e se simplificou bastante, o que estancou a fuga em massa de desenvolvedores para outras plataformas e parece que está ganhando adeptos.

Obviamente tudo que eu disso, IMHO.

Uma coisa eu concordo com o Rod, se as duas tecnologias ficarem brigando, logo, logo vamos ter Rails em todo canto…
Agora que o pessoal começou a saber java de verdade, e os projetos estão saindo melhores, não sei se seria interessante pegar a galera e reiniciar com uma nova linguagem, que na minha opinião, não acrescenta tanto para justificar sua existência… mas claro isso é a minha opinião…

Não tenho tanta certeza se por aqui as vagas de EJB3 são o que a gente mais vê hoje em dia, alguém se arriscou a fazer um comparação semelhante nos sites de vagas ???

Aqui eu vejo que teve um grande boom (boom de explosão de projetos que ficaram nojentos) por causa do EJB 2.x, o que fazia muita gente tremer ao ouvir falar em EJB, com a versão 3, quem foi se atualizando pode ver que o cenário é outro e valia a pena pensar novamente na tecnologia, tbm acho que aos poucos será feita a troca de spring por EJB 3.x.

Quanto as vagas, muito projetos usam o spring lá e nem sabem direito porque, como “não usam” na verdade nada do framework, ele ta lá só injetando alguma coisa, eles destacam EJB3 por realmente necessitar do conhecimento tecnico do desenvolvedor.

Acho esso sentimento do pessoal do Spring, e de seus avidos defensores, de dominancia e superioridade um imensa criançisse sem limites.

Falar que EJB 2 não presta é um imbecilidade, pois foi por conta dos erros do mesmo que o pessoal do Spring e de outras tecnologias conseguiram evoluir a ideia de desenvolvimento de aplicações empresariais. Foi com o erros do Spring que novas tecnologias também estão melhorando o desenvolvimento de aplicações empresariais. O mundo Java e de tecnologia é sempre uma evolução constante e parece que o Spring se acha no topo, ao lado dos deuses do olimpo, em todos os quesitos que você imaginar.

O que faz uma aplicação OTIMA não é o fato de utilizar Spring ou não, de usar EJB 3 ou não. O que faz uma aplicação de sucesso é um conjunto de fatores onde a tecnologia usada pouco importa, como processo, como ter a capacidade de elaborar prazos que realmente não alcançaveis, etc…

A verdade é que o Spring, apesar de uma otima solução até agora, não é mais a unica opção otima como anteriormente.

Para Java EE e melhor para aplicações empresariais :arrow: Seam
Para um DI realmente simples :arrow: Guice
AOP ??? :arrow: Who cares???
Web :arrow: JSF e Struts 2 -> Quem se importa com Spring MVC atualmente???

O mundo mudou e achar que Spring é a bala de prata, como milhoes de gente acha, é um atentado ao bom senso. Comparar Spring com EJB 2 é negar a evolução de outras plataformas.

É engraçado que esse sentimento só ocorre com o Spring, impressionante… Nunca vi o hibernate contra o JPA (que foi uma evolução natural das coisas), contra iBatis, contra Top link, apesar de serem concorrentes, parece que existe o minimo de respeito, imagino… Mas na camada transacional, a camada de negocios, PQP… Parece bicho, ou bichas, vai entender…

A questão não é se EJB é melhor ou pior que Spring.

E depois quando ele compara Rails a EJB e Spring eu realmente não entendi nada. O que EJB tem haver com Rails? Rails para sistemas disbribuídos? Acho que ele se confundiu…

A questão sobre EJB é que poucos projetos justificam o seu uso. E mesmo para esses poucos projetos vc pode tranquilamente usar outras soluções para sistemas distribuídos como xFire, RMI, SOAP, REST e por aí vai… E para mensagens assíncronas, mais raras ainda, vc pode usar openjms. Não vou entrar no mérito se essas soluções alternativas são melhores ou piores do que EJB. Eu particularmente sempre fugi e continuarei fugindo de applications servers.

Se alguém discorda por favor se manifeste: “A grande maioria dos projetos não são distribuídos logo NÃO precisam de EJB.” Usar EJB nesses casos é realmente lamentável, como sempre foi.

Só faltou ele dizer que o Rails é um lixo porque não tem chamadas remotas ou mensagens assíncronas…

Dependeeeeeee… Como tudo na vida depende… Concordo que o erro do EJB é negar pra que ele serve, que é o desenvolvimento de aplicações distribuídas. Mas o modelo do EJB3 agora suporta de forma não tao burocratica o desenvolvimento de aplicações nao distribuídas. O caminho dele é ser a solução para esses dois tipos de cenário.

Enfim, o que escolhe EJB3 e até EJB 2 ou não, é um plano de arquitetura que possui suas justificativas, que envolve familariedade dos desenvolvedores com a tecnologia, suporte decente dos fornecedores, etc. Escolher tecnologia só por ela faz tal coisa mais “bonitinha” é lamentavel, isso sim.

que o Spring nasceu como sendo a criptonita das “merdas” do java (como EJB2) que, somente com lavagem cerebral o pessoal acreditava que era bom (como alguns users do fórum que metem o pau no hibernate e defendem até a morte os Entity Beans do EJB 2.1) era o fator principal pra acreditar que num futuro não muito próximo que haveria uma certa dependência “extrema” entre Java e Spring (ou seja: se continuassem nessa linha de raciocínio do EJB) e agora estamos ae, colhendo os frutos

hoje em dia, pelo menos pra mim, spring se tornou algo que está em TODOS meus projetos: São tantas facilidades entregues de mão beijadas que parece que a cada dia a galera taca um f*-se no que vem de padronização da sun (como EJB). Qual a justificativa de se usar EJB?!

o que aconteceu é que a reviravolta que rolou no mundo JavaEE (1.4 -> 5) fez muitos desses conceitos serem repensados, cujo qual o principal seria “poxa, qual a necessidade de se usar Spring agora?”

só uma pergunta: quem aqui já usou o Seam?

quem já usou Seam pode afirmar que, se tem algo pra bater rails, o nome é JBoss Seam

Totalmente agreed! Quase me emocionei quando eu ví o Seam trabalhando hahaha =)

Um DI REALMENTE SUPER SIMPLES

Me =) você deve dizer isso porque não teve nenhuma situação cujo qual fosse realmente necessário

Realmente, nem você, nem eu, nem ninguém do fórum praticamente se importa com SpringMVC por fatores bem simples: Quem usa no Brasil?
Com excessão do Brasil, outros países como EUA, UK (e outros países europeus), India e afins, analizando as pesquisas, principalmente as que rolaram no Javapolis, mostram que pra Web o SpringMVC é o mais utilizado, seguido de JSF, Struts 1 e Struts 2

poxa depois eu posto mais, to ubber ocupado agora heuiaoea ;*

Não sei então se isso tem acontecido somente comigo, mas as últimas 3 empresas que passei, os sistemas eram/são realmente distribuídos, e a facilidade que EJB3 trouxe para este tipo de desenvolvimento, para mim não justificaria utilizar soluções como WS, SOAP, RMI, REST. Ainda mais com a facilidade de poder disponibilizar meus EJBs como WebServices para outras plataformas(que é o que eu tenho feito).

EJB2 concordo que era bem trabalhoso de se utilizar, mas ainda assim eu particularmente achava mais tranquilo de se utilizar com minhas equipes do que aquele monte de xmls do Spring. Com o advento do EJB3, eu não tenho nenhum motivo que me empolgue em utilizar Spring.

Ps: Estou me referindo unicamente a Session Beans.

Bill Burke só estava tentando botar medo para vender a idéia que os desenvolvedores Java têm que se unir sob a bandeira do EJB3 ou perecer de fome enquanto Rubyistas roubam seus empregos e suas mulheres.

Eu pessoalmente não entendo pra que perder tempo dando ouvidos a gente como o Mr. Burke, que não sabe nem quer saber o que é desenvolver uma aplicação pra resolver problemas do mundo real, e ainda desdenha de quem se preocupa em disponibilizar para outros soluções que funcionam para si em vez de se envolver com politicagem.

Leozin:

só uma pergunta: quem aqui já usou o Seam?

quem já usou Seam pode afirmar que, se tem algo pra bater rails, o nome é JBoss Seam

Se a única coisa que Java tem pra bater Rails é o Seam, então tá na hora de ir comprar os pregos do caixão :lol:

Eu já fiz alguns projetos usando o Seam pra Java ele realmente é uma mão na roda, especialmente considerando que JSF em si, purinho, é uma cagada completa (você só precisa ter que usar um select em um form HTML ou precisar de alguma coisa como os antigos templates do tiles). É tao complicado que pra tudo tem que ter framework, como Facelets pra templates, Seam pra DI e gerenciamento dos managed beans e frameworks de desenvolvimento de componentes.

Você já escreveu uma aplicação de verdade com Rails?

De qualquer forma, comparar Rails com frameworks em Java e querer dizer que “um concorre com o outro” ou “um é melhor que o outro” é perda de tempo. Ruby é Ruby e Java é Java, só sabe quem é melhor quem já esteve dos dois lados.

Maurício Linhares:

Se a única coisa que Java tem pra bater Rails é o Seam, então tá na hora de ir comprar os pregos do caixão :lol:

Eu já fiz alguns projetos usando o Seam pra Java ele realmente é uma mão na roda, especialmente considerando que JSF em si, purinho, é uma cagada completa (você só precisa ter que usar um select em um form HTML ou precisar de alguma coisa como os antigos templates do tiles). É tao complicado que pra tudo tem que ter framework, como Facelets pra templates, Seam pra DI e gerenciamento dos managed beans e frameworks de desenvolvimento de componentes.

Você já escreveu uma aplicação de verdade com Rails?

De qualquer forma, comparar Rails com frameworks em Java e querer dizer que “um concorre com o outro” ou “um é melhor que o outro” é perda de tempo. Ruby é Ruby e Java é Java, só sabe quem é melhor quem já esteve dos dois lados.

É eu trabalhei pouco com Rails mesmo e também acho du kr***

mas assim, tem algo que tu acha que em Java pode bater rails? Algo que pode se comparar com Rails? Ou você acha que cada um server pra uma coisa?

Leozin:

É eu trabalhei pouco com Rails mesmo e também acho du kr***

mas assim, tem algo que tu acha que em Java pode bater rails? Algo que pode se comparar com Rails? Ou você acha que cada um server pra uma coisa?

São coisas diferentes, e cada um tem o seu espaço, escrever uma aplicação web em Java hoje é uma má idéia, do mesmo jeito que escrever uma aplicação usando mensageria assíncrona em Ruby, assim como escrever uma aplicação de telas de cadastro e relatórios em Erlang. Bill e Rod estão defendendo os seus “produtos” e empresas, nós temos que defender os nossos empregos, não os deles.

Seria bom tentar entender muito bem entendido quais são os pontos fortes de RoR:

• Ruby é mais poderosa, mais pragmática, mais rápida (de se programar), mais amigável para expressar lógicas, tem closures, etc.

• Ruby é menos simples do que Java. (ponto fraco)

• Rails é FULL-STACK e isso pra mim faz toda a diferença. Conheço outros 3 frameworks em Java que são full-stack: Rife, Seam (graças ao JBoss logo poderia ser questionável) e XXXXXXXXXXX (estou proibido de citar esse último).

• Ruby tem metaprogramação e isso abre um leque de opções e sacadas maravilhosas. Será que o Java um dia terá um método Class.createMethod ?

• Não fale que Rails é bom porque tem Convention Over Configuration assim como vc não deve falar que ele é bom porque suporta validação.

• Aquelas sacadas de criar uma aplicação completa digitando rails addressbook é bem legal. Talvez isso seja equivalente a um bom plugin do Eclipse.

• ActiveRecord é legal. Me parece que toda essa flexibilidade e mágica é conseguida via metaprogramação, ou seja, impossível (por enquanto) em Java.

• Turnaround: Ruby não precisa compilar nem restartar nada quando vc está desenvolvendo. Isso sempre foi um problema do Java, mas tem empresas desenvolvendo soluções pra isso: JavaRebel (http://www.zeroturnaround.com/)

Eu nunca usaria Ruby ou RoR para um sistema/site mais parrudo e sinistro. Prefiro pagar o preço do Java mais ganhar de graça sua robustez e plataforma. Agora aplicações web, sistemas não-distribuídos com um front-end na Internet, etc. RoR cai como uma luva. E esses projetos me parecem que são a maioria. E cada vez que alguém escolhe utilizar EJB ou Spring para esses projetos está na minha opinIão colaborando sim para a migração de mais e mais gente para RoR, e com a devida razão.

O Seam é full stack? Desde quando? O Seam usa JPA ou Hibernate pra persistência, usa JSF pra view (eles vendem que dá pra colocar outras coisas, mas não é simples de se fazer). O Seam é um monte de glue-code pra tornar JSF e EJB factível em aplicações web comuns, uma tarefa tão titânica que deu num framework do tamanho do Seam.

E de qualquer forma, o ActiveRecord é externo ao Rails (agora no Rails 2 é externo “de verdade”), usa-se ele apenas por costume e falta de coisa melhor.

Esse é o peixe que eles vendem. Quando eles mostram um exemplo, eles só mostram um facade, um bean anotado com hibernate e pronto: a aplicação está funcionando. Eu acreditei…

Depender de Hiberante, JPA ou ActiveRecord me parece que não invalida o título de full-stack. O que se deve fazer é prover a melhor integração possível com esses frameworks já que eles têm altíssimas chances de serem utilizados.

O livro “Learning Ruby” fala o seguinte sobre a característica full-stack do RoR:

Esqueceram de citar o Grails. Eu estou adotando este framework e apostando bastante nele para a plataforma Java em desenvolvimento ágil. Uma porque Rails em AS é lento por culpa do JRuby. Outra porque Groovy está ficando interessante e, já roda em JVM com performance superior a JRuby.
O incrível que somente a Sun e a Oracle fizeram sites com JRuby e eles rodam legal. Agora, o que está por trás daqueles sites é que são elas. Precisa de servidor que criança não costuma ter pra brincar.

saoj, não entendi essa de Ruby é menos simples que Java?

Ruby tem conceitos bem mais complexos do que os de Java.

Maurício Linhares:

O Seam é full stack? Desde quando? O Seam usa JPA ou Hibernate pra persistência, usa JSF pra view (eles vendem que dá pra colocar outras coisas, mas não é simples de se fazer). O Seam é um monte de glue-code pra tornar JSF e EJB factível em aplicações web comuns, uma tarefa tão titânica que deu num framework do tamanho do Seam.

Na verdade o que o Seam fez foi tornar a necessidade de frameworks de terceiro praticamente nulas.

Eu to ligado que ele também vende poder utilizar outras coisas na web (com GWT em vez de JSF) mas não sei até onde vale a pena o esforço. Entre outra coisas, o “glue-code” do seam também cai como uma luva, você elimina uma porrada de camadas e sem contar que todo o “stub” que o seam-gen gera pra você acaba economizando um bom tempo em várias coisas

Apesar de muita gente criticar JSF, o Seam também não é um framework que “simplesmente usa JSF”. Ele tornou JSF algo muito melhor do que já era (tá, sou entusiasta de JSF então nem levem em consideração hahaha) como por exemplo a extensão do EL, a unificação de ManagedBean com Seam POJO Components (ou EJB3 Session Bean) e utilização de annotations pra criar validators e converters

Quando eu tinha me referido a Seam e Rails, o que levei em consideração, principalmente, é que da mesma forma que com Rails você não precisa de “mais nada”, o Seam também acaba sendo um framework completo. Não vou dizer que “ah o Seam é tão legal que ele QUASE usa um ActiveRecord” (…) porque não podemos também dizer que tudo que vem do RoR é a silverbullet e tudo que “segue esse caminho” está sendo algo que tende a ser a solução pra fome no mundo.

djemacao:

O incrível que somente a Sun e a Oracle fizeram sites com JRuby e eles rodam legal. Agora, o que está por trás daqueles sites é que são elas. Precisa de servidor que criança não costuma ter pra brincar.

Te passaram FUD. Groovy e JRuby têm performances semelhantes em termos de uso de memória e velocidade de processamento. JRuby só é significativamente mais lento no startup.

O sites que estou desenvolvendo utilizando Seam são os mais complexos que já fiz e por incrivel que pareça são os que estão ficando com a arquitetura mais simples. Mas como não existe País das Maravílhas, aplicar uma estratégia TDD com o Seam não é fácil, exatamente porque o framework é um monstro. Estamos discutindo isso aqui:

http://www.guj.com.br/posts/list/81757.java

Posso mostrar exemplos bem complexos de aplicações Seam, coisas que integram Ajax, Jbpm (com Forks), Mensagens Assincronas e etc… A única coisa que estou esbarrando nele realmente é o TDD.

rubinelli:

djemacao:

O incrível que somente a Sun e a Oracle fizeram sites com JRuby e eles rodam legal. Agora, o que está por trás daqueles sites é que são elas. Precisa de servidor que criança não costuma ter pra brincar.

Te passaram FUD. Groovy e JRuby têm performances semelhantes em termos de uso de memória e velocidade de processamento. JRuby só é significativamente mais lento no startup.

Ruby tem conceitos bem mais complexos do que os de Java.
Posso estar enganado, por já conhecer coisas esquisitas como Perl, mas se contar com os inúmeros Patterns que somos obrigados a engolir pra sanar alguma deficiência da linguagem, acho que deveríamos desconsiderar esta avaliação .

Alguém saberia me dizer se o Grails é sem turnaround como o Rails?

A grande vantagem do rails, além de funcionar, e bem, é que ele é 1 só. nada de spring, struts, ejb2, ejb3. Os caras trabalham em 1 só coisa o tempo todo, e parecem a apple de tanta facilidade que criam :). A própria metaprogramação suportada pelo ruby faz com que a criação de xml seja uma coisa pra lá de idiota. Pior que isso, usar o ActiveRecord é algo que faz mal a mente. É tão simples fazer relacionamentos, criar um novo modelo, manter seu código, que você enjoa das outras linguagens e soluções existentes no mercado.

Não sou defensor ferrenho do RoR, mas a gente tem muito o que aprender com eles…

Meu medo do RoR é ele sair do nicho que o saoj comentou, aplicações mais simples e que não exigem alta disponibilidade ou processamento distribuído e cair para sistemas pesados de verdade, pq teve um carinha no desenvolvimento lá que gostava RoR e fez.
Pq aí sobra pra dar jeito nesse tipo de projeto, problemas de performance, disponibilidade, etc… e aí quando falamos que tem que refazer os GPs vão dar xiliques…

otaviofcs:

A grande vantagem do rails, além de funcionar, e bem, é que ele é 1 só. nada de spring, struts, ejb2, ejb3. Os caras trabalham em 1 só coisa o tempo todo, e parecem a apple de tanta facilidade que criam :). A própria metaprogramação suportada pelo ruby faz com que a criação de xml seja uma coisa pra lá de idiota. Pior que isso, usar o ActiveRecord é algo que faz mal a mente. É tão simples fazer relacionamentos, criar um novo modelo, manter seu código, que você enjoa das outras linguagens e soluções existentes no mercado.

Não sou defensor ferrenho do RoR, mas a gente tem muito o que aprender com eles…

Conheça Grails, ele aprendeu muito com RoR.

reinaldob:

Meu medo do RoR é ele sair do nicho que o saoj comentou, aplicações mais simples e que não exigem alta disponibilidade ou processamento distribuído e cair para sistemas pesados de verdade, pq teve um carinha no desenvolvimento lá que gostava RoR e fez.
Pq aí sobra pra dar jeito nesse tipo de projeto, problemas de performance, disponibilidade, etc… e aí quando falamos que tem que refazer os GPs vão dar xiliques…

E escrever a aplicação em Java vai evitar isso?

Incompetência é independente da linguagem ou ferramenta que as pessoas estiverem utilizando. Se eles não sabem nem escolher a tecnologia certa pra escrever a aplicação, vão dançar em qualquer uma das possibilidades, escolher um ou o outro não vai facilitar a vida deles não.

reinaldob:

Meu medo do RoR é ele sair do nicho que o saoj comentou, aplicações mais simples e que não exigem alta disponibilidade ou processamento distribuído e cair para sistemas pesados de verdade, pq teve um carinha no desenvolvimento lá que gostava RoR e fez.
Pq aí sobra pra dar jeito nesse tipo de projeto, problemas de performance, disponibilidade, etc… e aí quando falamos que tem que refazer os GPs vão dar xiliques…

Não sei, não vejo o pessoal de PHP migrando pra Rails não. Acho que as maiores “viradas” tem sido o pessoal de Java e .Net mesmo.

Acho essa discussão a respeito de EJB e Spring uma grande falta de foco em relação aos problemas reais que acontecem na plataforma Java.Concordo com o Hal Jordan,o grande desafio é a melhoria(ou pelo menos a aplicação!) de processos de desenvolvimento e arquiteturas capazes de digerir mudanças tão rapidamente e independente de ‘novas conjecturas’,de modo que as aplicações atuais não se tornem ‘legadas’,e sim facilmente atualizadas,quando nescessário.

Acredito que a plataforma se encontra num estágio maduro o suficiente para se desenvolver mais ainda e com pequeno risco de perder espaço para Rails,Groovy e semelhantes(tais linguagens tem sim o seu espaço,mas não de uma maneira ampla como Java e sim atacando os pontos fracos de maneira a se tornar um ótimo complemento),desde que haja uma união dos membros da comunidade para os verdadeiros problemas.

Para exemplificar esse aspecto,desenvolvo sistemas corporativos para uma grande empresa de seguros que ainda tem como padrões o uso de EJB 2.1 e Struts 1.1 há pelos 4 anos com uma arquitetura bem rígida e, a meu ver,eficiente.A rigidez nas regras mais o uso de ferramentas apropriadas facilitou a criação de novas ferramentas mais específicas e aplicações a ponto de se tornar uma tarefa simples possibilitando até um desenvolvimento mais ágil(tirando a burocracia!).

Acho que essa aproximação também pode valer para aplicações menores,tiradas as devidas proporções. :shock:

Leozin , vi que fez uma menção ao SpringMVC e para falar de cases do Brasil, eu o utilizo em diversos projetos Web. Até se você der uma vasculhada no guj, vira e mexe eu o urubatan e o Maurício; respondíamos grande parte das dúvidas da galera.

Quanto ao projeto que você disse que ninguém dá importância, ele é a base do controle MVC do Grails. É um framework muitíssimo poderoso e pouco utilizado aqui no Brasil. No Spring 2.5, a metaprogramação o tornou simples, baseado em anotações :-).

Falando em RoR e aplicações distribuídas, queria saber como o pessoal do RoR resolve a questão de separar uma classe de negócio que envolve uma série de objetos de domínio.

Já falei disso uma vez com o Shoes , ele referenciou DDD e o model. Até voltei no livro do Evans e ele mesmo diz para externalizar em classes quando envolve outros objetos de domínio.

Passamos anos tentando ensinar a galera do Service-to-worker à não colocar suas regras nas Actions. E o que vejo no RoR ? Regras de negócio totalmente amarradas, sem possibilidade de migração entre projetos.

O Grails possui a possibilidade de estender essa característica pelo DI do Spring, separando a camada de negócios e a disponibilizando num GigaSpaces por exemplo. Assim, você consegue resolver o problema de aplicação distribuída de forma simples e fácil~.

º~s

Kenobi .

Já que o Ruby é pragmático em tudo, a galera resolveu ser pragmático até nisso. Não que eu ache que isso esteja errado, pois acelera o desenvolvimento e corta a burocracia pela metade, mas no longo prazo não sei não…

Um dos motivos de fazer isso é que se amanhã você quer transformar a sua lógica de negócios em um web services, você pode facilmente. Facilita os testes também. Permite reutilizar a camada de negócios em outros lugares (na prática é raridade!), etc. Acho que organiza e facilita a manutenção como um todo.

Não que essa separação tb não possa ser feita com Ruby, mas parece que não é isso que a galera tem feito por aí… Tb fiz um comentário interessante sobre o problema de escopo de variáveis no Ruby aqui: http://www.guj.com.br/posts/list/15/82037.java

A moda era Struts, nós é que fomos pelo caminho errado

O Spring MVC é muito bom, só é complicado de você pegar de primeira por causa da grande quantidade de actions. Se o cara não ler a documentação direitinho não vai saber pra que serve cada uma e quando usar.

Kenobi:

Falando em RoR e aplicações distribuídas, queria saber como o pessoal do RoR resolve a questão de separar uma classe de negócio que envolve uma série de objetos de domínio.

Já falei disso uma vez com o Shoes , ele referenciou DDD e o model. Até voltei no livro do Evans e ele mesmo diz para externalizar em classes quando envolve outros objetos de domínio.

Passamos anos tentando ensinar a galera do Service-to-worker à não colocar suas regras nas Actions. E o que vejo no RoR ? Regras de negócio totalmente amarradas, sem possibilidade de migração entre projetos.

Isso aí é POG de quem está programando as aplicações, o mínimo que se espera de alguém que está fazendo uma aplicação com um framework web baseado em actions é que ele saiba que a action/controller só deve ter lógica de roteamento, ela não deve ter nada de lógica de negócios, a lógica de negócios fica nas entidades e nos serviços.

Kenobi, no RoR a integração é feita com REST. O mesmo controller que manda renderizar HTML manda gerar XML ou JSON. Ainda assim, todos os desenvolvedores experientes são unânimes em condenar controllers gordos e enfatizam que a lógica de negócio deve ficar no modelo, que é facilmente desacoplado do resto do framework.

Falae Kenobi, tudo bem?

Desculpa se eu pareci não mostrar direito o meu ponto de vista, mas quando me refiro a cases do Brasil a gente pode ter como base principal o mercado: Quantas empresas você já viu no NetCarreiras ou na apinfo pedindo Spring MVC? E quantas empresas pedem SpringMVC em sites como monster.com? Se for falar “ah eu e o urubatan usamos” não tem relevância nenhuma, da mesma maneira que se eu dizer que uso Guice.

Mas mesmo assim tu concordou comigo, pelo menos é o que deu a entender:

Gostaria de dizer também que não estou falando mal do SpringMVC, longe disso hehe (não é esse o objetivo!) pra mim é um dos melhores frameworks web, já utilizei e aprovo. Mas ainda o mercado brasileiro não conhece nem sequer Spring, imagina SpringMVC, são poucas empresas que utilizam e “nem tantos” usuários “brincam” ou fazem projetos pessoais com o SpringMVC.

Sim você voltou ao mesmo ponto da minha pergunta. E se você precisa externalizar sua lógica, pois trata diversos models num único processamento. A regra de negócio pode ser embutida num modelo rico DDD, desde que seja intrínseca ao que se refere.

Entendeu a questão ?

Bom galera , teva uma atualização legal nessa discussão. Estou aqui no Campus Party e bati um longo papo sobre o assunto com o Fábio Akita, acompanhado de perto pelo Louds.

Acho que vou bloggar sobre isso. Você tem a opção de colocar em Libs e chamar da Action, escrever um plugin que envolve seu negócio e models ou ainda mandar por mensagens, com um application server externo processando somente seus negócios. Essa é a maneira que faz mais sentido para um cenário distribuído e vou tentar escrever um pouco mais sobre o papo juntamente que tive.

Mas uma conclusão saiu da conversa - O Grails vem com esse suporte e pode ser um caminho interessante. O Akita disse que está achando bastante interessante alguns approaches do mesmo.

º´~s

Kenobi

Taí uma perguntinha boa pra um SCBCD responder…

Mauricio Wrote…: A moda era Struts, nós é que fomos pelo caminho errado

:lol:

Pois é, eu espero continuar andando por esses “caminhos errados” por muito tempo ainda

Primeiramente, queria parabenizar as pessoas dessa thread por conseguir gerar três páginas de conteúdo sem descambar pra idiotice ou pra agressão pura e simples (algo que está sendo raro ultimamente).

Mas indo à discussão, gostaria de expressar a minha opinião sobre as tecnologias citadas anteriormente:

:arrow: EJB3
Por EJB2 ser considerado uma unanimidade em quesito ruindade, fazer comparação entre esta e o EJB3 faz com que esse último aparente ser a última bolacha do pacote. Porém, tenho algumas restrições:
a) Por que a existência de inteface local e remota? Isso não poderia ser resolvido automaticamente? Do tipo: (o bean tá no mesmo nó) ? local : remoto.
b) Por que a anotação @EJB só funciona em Servlet, em Managed Bean ou eu outro EJB? E os outros objetos? Apelam pro Context?
c) Será que adianta correr o risco de de fazer um Big Design Up Front, colocando EJB porque se espera que, quando precisar escalar, basta “simplesmente” trocar tudo pra Remote (e torcer pra não reter ou transferir grande quantidade de bytes)?

:arrow: JSF
Sozinho, o Faces não faz verão. Precisa de uma porrada de bibliotecas e frameworks complementares para que fique algo decente. Nada contra, contanto que as pessoas se convençam de um simples fato: se quer algo completo, não use JSF!

:arrow: Seam
Olhando o que Seam faz, parece uma revolução. Mas não caio de amores tanto assim porque:
a) A anotação @Name me deixa com o pé atrás. É fácil declarar um managed bean desse jeito, concordo. Mas me dá uma sensação de estranheza quando a declaração de instância e a declaração de classe estão coladinhos, um embaixo do outro. Posso estar sendo careta, mas pra mim classe e objeto são coisas distintas e devem ser declarados em locais separados, juntá-los força uma relação nociva de 1 para 1 entre instância e tipo.
b) Seam é difícil quando o container não é o JBoss. Olha, tentei configurar sobre Glassfish v2, e não consegui rodar nem Hello World direito. No JBoss, consegui graças ao Sean-Gen, mas dá aquela sensação: “Não é assim uma Brastemp (ou melhor: um Rails)”.
c) Anotação é legal, mas precisa ser um framework onde o desenvolvedor tem que colocar TRÊS ou QUATRO anotações uma classe? Estamos trocando a era do XML hell para o Annotation hell!

:arrow: Spring
Já tive “nojinho” de Spring. Mas ultimamente estou gostando mais dele. A razão é que o framework está abrindo as portas para anotações e uma solução Faces, Spring e Spring WebFlow é mais simples que Seam com jBPM. Spring tem o problema de XML, mesmo usando autowired; mas a grande gama de serviços oferecidos, e ainda o fato de os grandes frameworks oferecerem suporte a Spring, compensa seu uso.

:arrow: Groovy
Desculpe-me aqueles que gostam dessa linguagem, mas Groovy é o C++ dos novos tempos! Assim como C++ tentou conciliar o paradigma OO de alto nível com o paradigma de proximidade de máquina, o Groovy tenta conciliar uma característica dinâmica com uma linguagem estática. O resultado é um só: complexidade. E é fácil reparar nisso, lembro de um programa C++ em que se abria um arquivo com fopen ao invés do iostream porque o programador simplesmente não conhecia profundamente C++. Com Groovy, um programador que também não tenha muitos conhecimentos pode simplesmente ser tentado a fazer algo parecido com Java, mesmo que não seja a melhor solução.
Além disso, a escolha de Groovy por alguns fãs de Java é puramente ideológica! Já viu alguém desse fórum reclamando pra um rubista que Django (Python) ou CakePHP (PHP) é melhor que Ruby on Rails em determinado aspecto? Lógico que não! Alguns aqui escolheram Grails porque, de todos, é “o que tem mais Java, e se tem Java é bom”. Concordo que com Grails, a integração com Java é mais fácil, mas é um pensamento de curtíssimo prazo! Daqui a pouco, outras linguagens terão integração com Java e serão mais rápidas, fazendo com que a vantagem do Groovy desapareça, sendo apenas lembrado como o mais complicado das linguagens dinâmicas.

Acho que quando vc falou “escalar” vc queria dizer “distribuir”. Para distribuir pode-se usar xFire, RMI, Soap, REST, etc. Eu acho que não vale a pena fazer um design gordo up front.

Como eu postei anteriormente, a galera do RoR enche a boca para falar que da sua característica full-stack. O famoso: “Não me faça correr atrás de um monte de frameworks diferentes”. Se um cara é um mega arquiteto que domina um monte de frameworks Java e sabe integrá-los com perfeição, então isso é bom pra ele. Mas ele não é a regra!

Faço das suas palavras as minhas. Struts2 também resolve o XML hell oferecendo um annotation hell.

Spring simplifica o EJB. Até EJB3, Spring dava uma coça no EJB. Spring também serve para IoC/DI/Autowiring, mas muitas pessoas usam ele só para isso, daí pode ser considerado um exagero. Há outras soluções tão boas quanto o Spring para IoC/DI/Autowiring…

Spring tem outras coisas muito legais tb…

Não manjo muito de Groovy, mas com (J)Ruby e agora Scala vai ficar difícil pra ele.

Leonardo! Parabens pelo excelente post!

Sobre EJB3:

a-) As vezes voce quer fornecer menos visibilidade ao cliente remoto que ao cliente local. Realmente nao ocorre muito, mas esse é um dos motivos pelo qual nao é utilizada a mesma interface para os dois.

b-) Porque apenas Managed Beans, EJBs e Servlets não são instanciadas por voce, e sim pelo container. Como ele iria injetar algo em um POJO que voce mesmo é quem da new? Precisaria de manipulacao de bytecode das grandes (interceptacao do construtor), e seria estranha essa injecao.

c-) Na minha opiniao adianta sim, mas voce precisa ja pensar em criar algumas classes com metodos de granularidade maior, que servirão como façade, para evitar isso que voce falou: a grande quantidade de bytes transferidos quando a aplicacao se tornar realmente distribuida. Mas isso vale para qualquer tecnologia remota, nao é verdade?

Nâo acredito que o RoR venha a dominar o mercado e “roubar” o espaço do Java.
Na realidade, acredito que RoR venha a ocupar o espaço do “PHP”. Ao participar de um evento sobre Ruby on Rails aqui em Minas, percebi que 90% da platéia era composta por gente que trabalhava com PHP. Se RoR vai “tomar” o lugar de alguém, este alguém será o PHP, isto se conseguirem resolver os problemas atuais de performance e escalabilidade do RoR (o que com certeza vão).

Com relação à plataforma Java, acredito que um caminho com certeza será o Grails, ele trás algumas das vantagens do RoR e ainda nos trás algumas vantagens em relação àquele:

• Reaproveitamento de nosso código legado feito em Java (tá, tem o JRuby também, mas o Grails ainda está na frente do RoR sendo executado em JRuby). O Grails é executado NA JVM gente!

• Um ambiente completo de fato. Você nem precisa se preocupar com um banco de dados, ele já vem com o HSQLDB embutido.

• Muito mais fácil de se fazer deploy do que o RoR

• É baseado em tecnologias que já estão mais que consagradas: Spring + Hibernate, a dobradinha que o JEE 5 usou como fonte de inspiração

• Detalhe bobo mas não tanto para os iniciantes: por mais incrível que pareça, é MUITO mais fácil de instalar do que o RoR (nada de GEM, simplesmente baixe o pacote, descompacte e define a variável de ambiente GRAILS_HOME)

• Assim como o Rails, você nem precisa parar o servidor para alterar sua aplicação.

• Vender Grails é muito mais fácil que vender RoR. Basta dizer que é executado na plataforma Java.

• Na minha experiência, tem mostrado performance e escalabilidade melhor que RoR.

Sem sombra de dúvidas, é o framework para desenvolvimento web mais produtivo que já conheci.

Tenho investido muito no Grails ultimamente (até criei o primeiro grupo de usuários do framework (http://www.grailsbrasil.com) aqui do Brasil). Acredito que para o desenvolvimento de aplicações web em Java, seja o caminho mais interessante atualmente. Pensem: em qual PLATAFORMA vocês apostariam uma aplicação de grande porte? Ruby ou Java?

E outra: Java está deixando de ser visto como linguagem, e passando a ser visto como deveria ser desde o início: como PLATAFORMA. E,querendo ou não, uma das melhores se não A melhor.

E gostaria também de aproveitar para fazer uma profecia: RoR vai ser o VB da próxima década. Tenho visto MUITA gente despreparada desenvolvendo “aplicações” em RoR que, ao serem analisadas, mostram-se um lixo. Preparem-se para, no futuro, dar manutenção em sistemas de merda. (não que sistemas de merda não vão ser feitos em Grails, mas normalmente quem trabalha com Grails já trabalhou com Java, e quem eu tenho visto trabalhando com RoR normalmente não saca NADA de OO ou arquitetura pois só fazia sites simples em PHP).

Esta é a minha opinião a respeito da tal “dominação do mundo pelo RoR”

saoj:

Não manjo muito de Groovy, mas com (J)Ruby e agora Scala vai ficar difícil pra ele.

kicolobo:

Nâo acredito que o RoR venha a dominar o mercado e “roubar” o espaço do Java.
Na realidade, acredito que RoR venha a ocupar o espaço do “PHP”. Ao participar de um evento sobre Ruby on Rails aqui em Minas, percebi que 90% da platéia era composta por gente que trabalhava com PHP. Se RoR vai “tomar” o lugar de alguém, este alguém será o PHP, isto se conseguirem resolver os problemas atuais de performance e escalabilidade do RoR (o que com certeza vão).

Tipo, o Twitter roda em Rails e tal…

E você acha que o JRuby roda aonde se não for na JVM?

Tem “cap deploy” no Grails? Que implanta tudo em infinitos servidores sem você mexer mais do que dois dedos?

Vixe, ele não entra no path sozinho e ainda tem que colocar variáveis de ambiente? (sem contar que você não pode colocar o Grails em diretórios que tenham espaços, acentos, nem no diretório raiz)

Quando você instala o Rails é só “gem install rails”, você não precisa ir a site algum pra fazer nada e ele mesmo se configura na sua máquina, sozinho. O meu Grails aqui não fez nadinha sozinho

E Rails não roda na plataforma Java com JRuby?

Aiaiai, o cara programa em PHP e é um incompetente? Tipo, o Wordpress é em PHP, o YouTube é em PHP… preconceito faz mal rapaz, muito mal :lol:

Eu, pessoalmente, quase conto nos dedos os “escrevinhadores” Java que eu chamaria de programadores, não é porque o cara enche a boca pra dizer que programa em Java que ele sabe alguma coisa não, o que não falta no mercado é falador que não sabe fazer nada. Pelo menos a galera do PHP resolve os problemas, em vez de ficar discutindo o sexo dos anjos ou inventando compĺicação onde tudo poderia ser simples.

djemacao:

Scala é interessante, e JRuby muito legal, mas a pergunta que fica é:
Scala tem um framework bacana pra Web? Se tiver, há salvação neste mundo .

Nada tema companheiro, o mundo ainda tem salvação => http://liftweb.net/index.php/Main_Page

Maurício Linhares:

djemacao:

Scala é interessante, e JRuby muito legal, mas a pergunta que fica é:
Scala tem um framework bacana pra Web? Se tiver, há salvação neste mundo .

Nada tema companheiro, o mundo ainda tem salvação => http://liftweb.net/index.php/Main_Page

Droga! Eu queria dormir . Mas agora Maurício, vou ser obrigado a ver isso.
O pior é o vício. Num deveria ter passado isso. Agora já era. Bom, 4 da matina, lá vou eu.

Valeu :thumbup:

O lift é bem legal mas eu aind não consigo ver Scala como uma opção tão forte. Scala enquanto trabalho científico é fantástica mas a ausência de uma interface mais humana é problemática. Acho que a linguagem deveria seguir o princípio de Lisp. Apesar da problemática sintaxe Lisp tem uma vantagem: você não programa (muito) em lisp, programa em DSLs e por isso consegue lidar com complexidade muito alta de maneira muito simples.

Acho que a próxima grande linguagem vai trazer macros para o average joe. Ainda não vi a sombra dessa no horizonte, entretanto.

O Facebook é feito todo em PHP. E vale 15 bilhões de dólars. 2% foi vendido para a Microsoft por quase 300 milhões de dólares.

pcalcado:

Acho que a próxima grande linguagem vai trazer macros para o average joe. Ainda não vi a sombra dessa no horizonte, entretanto.

Que os anjos digam amém.

Mas você acha mesmo que os average joes vão chegar nesse nível?

Eu não tenho mais tanta fé nisso.

Se a sintaxe for razoável, sim. Não é mais fácil criar um framework caseiro Java (mesmo que um podre) do que lidar com macros, o que ferra tudo é (1) sintaxe arcana e (2) mudar paradigma. O paradigma já está mudando…

Mas eu acho que isso é apenas um estado transitório pré–language workbenches. Quando passar essa fase acotnece o grande cisma de TI ™

pcalcado:

Se a sintaxe for razoável, sim. Não é mais fácil criar um framework caseiro Java (mesmo que um podre) do que lidar com macros, o que ferra tudo é (1) sintaxe arcana e (2) mudar paradigma. O paradigma já está mudando…

Mas eu acho que isso é apenas um estado transitório pré–language workbenches. Quando passar essa fase acotnece o grande cisma de TI ™

Mas você acha que o paradigma está mudando pra eles no curso prazo?

Eu ainda vejo tanta gente programando em JavaScript sem saber a diferença entre o nome da função sozinho e o nome da função com parênteses no final que eu não consigo ter fé de que isso mude tão cedo.

Não sei porque mas esse papo todo de macros me lembrou de Fortran :shock:

medo++

É difícil responder sua pergunta, o mundo de TI é assíncrono. O que para alguns e curto prazo para a maioria demora. EJB não demorou muito para ser ‘desmascarado’ mas demorou anos para ‘without EJB’ virar mainstream. Da mesma maneira linguagens para JVM só atingem o maisntream agora e existem há anos. Uma coisa é mais ou menos certa no padrão: o mainstream não saem do padrão nada. Os alpha-geeks criam ou pensam em algo, em algum tempo isso vai para o mainstream ou não. Não consigo lembrar de nada que não siga este padrão e tenha durado mais que uma tentativa frustrada de vender um produto.

Resumindo: os alpha-geeks estão correndo para isso. Mesmo pessoas que nunca se interessaram tanto por alguns conceitos (eu incluso) estão (re-)aprendendo as coisas básicas de linguagens de programação. Fatalmente isso ou chega no mainstream ou continua no mesmo saco de gatos onde se encontra a maioria dos avanços reais na área, como Lisp, Haskell e Smalltalk.

Eu possoe star errado mas pelo que sei macros FORTRAN estão mais para macros C do que macros Lisp. Macros em Lisp são funções din6amicas, não transformações estáticas de código, por isso C não ter nem perto do poder das macros de Lisp.

Então a hora agora é de cruzar os dedos e tentar dar uma empurrada nisso

E falando em Smalltalk => http://squeakbyexample.org/

Quando o assunto não é mais um simples CRUD, e há necessidade de transacionar operações entre diferentes aplicativos distribuídos em uma mesma rede, sendo, contudo, executandos em servidores de aplicações diferentes, EJB3 é uma boa solução.

Atualmente estou envolvido em um projeto desses (e no passado estive em outros), assim como já estive em projetos em que Spring era uma boa opção (e foi a escolhida).

Pensar que algo não serve absolutamente pra nada me parece um pensamento muito minimalista. Como o CV bem disse no último CJ, isso é coisa de Arquiteto de uma nota só!

Usar Spring apenas pra IoC? Usar EJB pra CRUD? Fugir de application server como o diabo foge da cruz? Hummm… Prefiro pensar um pouquinho mais.

Cada tem seus requerimentos particulares, bem como cada tecnologia a sua aplicabilidade…

IMHO

Tem “cap deploy” no Grails? Que implanta tudo em infinitos servidores sem você mexer mais do que dois dedos?

Maurício, no Grails você pode optar por deployar num WebLogic a vida, que ele faz automaticamente o deploy em todas as instancias que estão no cluster.

Não estou defendendo, somente dando uma solução para o problema.

saoj:

Maurício Linhares:

Aiaiai, o cara programa em PHP e é um incompetente? Tipo, o Wordpress é em PHP, o YouTube é em PHP… preconceito faz mal rapaz, muito mal :lol:

O Facebook é feito todo em PHP. E vale 15 bilhões de dólars. 2% foi vendido para a Microsoft por quase 300 milhões de dólares.

Não significa que seja bem implementado ( Não estou dizendo que não seja) . Mas o valor da companhia é muito mais inerente ao modelo de negócios, marketshare do que tecnologia propriamente dita.

Só pra deixar claro.

Nada tenho contra o PHP. Eu mesmo tenho diversos projetos feitos em PHP, mas convém mencionar a existência dos “programadores”. No meu dia a dia, quando tenho de contratar alguém, é extremamente comum me deparar com gente que diz que desenvolve em web com PHP e, no final das contas, não faz práticamente nada.

Óbvio que PHP não é uma linguagem de merda, mas é nítida a imensa legião de “programadores/desenvolvedores/ou o nome que você quiser” que, usando o fato de fazer scripts bestas em PHP, queimam o filme de toda a nossa categoria. Este é um fato de mercado. Não há dúvidas com relação a isto.

Que há projetos feitos em PHP de incrível qualidade, não há dúvidas também. Basta ver que a popularidade do PHP é muito maior do que JSP/JSF/Grails/RoR ou qualquer outra linguagem para desenvolvimento web. É uma plataforma interessante para se trabalhar, não resta dúvidas. Mas, HÁ este lado negativo também.

Assim como ocorreu com o desenvolvimento em Delphi e VB, o mesmo ocorreu com o PHP, não há muito como negar. Pessoas que não sabem o básico (e são muitas, acredito que a maioria) de arquitetura de sistemas estão aí desenvolvendo “sistemas” em PHP que, quando você pega trabalhar, são um desastre.

Sugiro que vocês comparem os artigos escritos aqui no Brasil a respeito de PHP e outra linguagem mais OO como Java por exemplo. Vão ver nítidamente que o nível técnico É inferior na maior parte das vezes. Basta olhar o nível de discussão que temos aqui no GUJ e o nível de discussão que você vai encontrar em uma comunidade sobre PHP. O mesmo digo com relação tanto ao Delphi e VB (detalhe: trabalho tanto com Delphi quanto VB também. não é preconceito CONTRA a plataforma, mas sim CONTRA um certo tipo de profissional que prolifera na mesma, e acaba DESTRUINDO a credibilidade da mesma).

Maurício, YouTube é escrito em Python.

** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock:

Kenobi:

Maurício, no Grails você pode optar por deployar num WebLogic a vida, que ele faz automaticamente o deploy em todas as instancias que estão no cluster.

Não estou defendendo, somente dando uma solução para o problema.

Considerando que o custo de licença pelo Capistrano, um servidor unix com shell, apache e alguns mongrels é zero, acho que é mais fácil pegar Ruby e Rails né

Mas é exatamente esse o ponto, a tecnologia hoje é o mínimo dos seus problemas (na verdade, faz muito tempo isso já, uma lidinha em Peopleware ou The Mythical Man Month já mostram isso). As tecnologias só afundam projetos de quem realmente não sabe nada ou não tem direcionamento nenhum (ou realmente não sabia nem escolher o que deveria usar).

Maurício Linhares:

Considerando que o custo de licença pelo Capistrano, um servidor unix com shell, apache e alguns mongrels é zero, acho que é mais fácil pegar Ruby e Rails né :)

Aí que tá, o mesmo você pode dizer do Tomcat ou o JBoss por exemplo. Dá na mesma.
Custo financeiro aqui não conta mais.

Javabuntu:

** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock:

Eu não acho que Ruby o Rails vá ‘roubar a cena do java’, apesar de achar que ‘a cena do Java’ tem dias contados, mas só um exercício: você se lembra quando java chegou ao topo dessa lista? Ou quando comemoramos que Java tinha mais projetos que C+ no SourceForge? Lembra quando tudo o Brasil era Delphi, ASp e PHP e Java era ‘muito lenta, não tem boa ferramenta’, etc.?

Sinceramente, eu não sei se as pessoas esquecem ou simplesmente não viveram isso.

pcalcado:

Javabuntu:

** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock:

Eu não acho que Ruby o Rails vá ‘roubar a cena do java’, apesar de achar que ‘a cena do Java’ tem dias contados, mas só um exercício: você se lembra quando java chegou ao topo dessa lista? Ou quando comemoramos que Java tinha mais projetos que C+ no SourceForge? Lembra quando tudo o Brasil era Delphi, ASp e PHP e Java era ‘muito lenta, não tem boa ferramenta’, etc.?

Sinceramente, eu não sei se as pessoas esquecem ou simplesmente não viveram isso.

Na sua opinião, o que virá a substituir o lugar do Java (linguagem) atualmente?

Pessoalmente, acredito que daqui pra frente Java passará a ser a ser visto cada vez menos como linguagem e mais como plataforma de execução (o que de fato sempre foi desde o início), pois estão surgindo diversas novas linguagens para a plataforma (Groovy, JRuby, Scala, Grails, etc.), ao passo que a linguagem Java, em si, já está chegando ao fim de sua própria evolução (não que a linguagem Java vá morrer, mas sim vai dar uma “estacionada”).

Sim, por aí. Não vai ter uma coisa que vai substituir Java, simplesmente as pessoas vão voltar para o ponto onde se escolhia a ferramenta certa para o problema. A JVM tende a ser apenas uma entre diversas outras plataformas que dao suporte à essas liguagens.

O futuro de Java é como plataforma. Esse é um lance que a Microsoft atacou com .Net desde o início, e que a Sun também tem despertado e investido. Alguns exemplos disso? JRuby, Groovy, Projeto Da Vinci Machine…

Falei um poucou sobre isso recentemente em meu blog:

• A Plataforma Java não é sobre a linguagem Java
• Não há uma única linguagem de programação
• Projeto Da Vinci Machine

Isso é muito louco. A veia da idéia é: Seja livre pra escolher a linguagem que melhor atenda às suas necessidades, que melhor resolva seus problemas computacionais, sob todos os aspectos.

Agora, o maior obstáculo que eu vejo nisso são os prograadores que acham que Java é a melhor linguagem de programação do Universo. Java não foi concebida para resolver todos os problemas computacionais do Universo, basta ver a sua história.

Eu acho um absurdo esse tipo de pensamento. Porque, não é porque Java tem API e framework [bizarro] pra tudo, que ela seja a melhor opção também em tudo.

Na boa? Não acho que a “linguagem” Java vá morrer não, porque ela tem os seus méritos e a sua aplicabilidade - todos nós aqui programamos em Java e sabemos disso. Mas também não acho vá continuar por cima da carne seca por mais muitos anos.

O que eu penso? Penso que ela vai ser só mais uma (ainda que boa) opção como linguagem de programação para a JVM. Não acho que vá ser a melhor, nem a pior. Acho que vai ser apenas mais uma opção. Lembrando, claro, que opção se faz com parametros, senão não é opção, é “goela abaixo”, “lavagem cerebral”, qualquer coisa, menos opção.

Tal como acontece na plataforma .Net você pode resolver problemas computacionais com C#, VB, IronPython, ou sei lá mais o que, dependendo do problema em questão, creio que na plataforma Java acontecerá. (Nesse ponto temos que tirar o chapel pra Microsoft, porque eles “se inspiraram” em Java e fizeram aquilo que Java deveria ter feito desde o início).

E viva a liberdade de escolha!

melhor crítica à Ruby ever:

Como viver sem o “Open Call Hierarchy” ???

Isso me assusta um pouco. As facilidades do Eclipse para o Java, tais como auto-complete, refactoring, auto-compile, show call hierarchy, etc. agilizam muito o desenvolvimento e a manutenção de um projeto grande, cheio de classes.

E a característica do Ruby de ser Dynamic Typing, parece que vai de encontro a isso.

Fonte: http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-ruby.html

kicolobo:

Aí que tá, o mesmo você pode dizer do Tomcat ou o JBoss por exemplo. Dá na mesma.
Custo financeiro aqui não conta mais.

Aí é que tá, você primeiro descobre o que o Capistrano faz -> http://www.capify.org/getting-started (leia esse getting started, basics e rails)

Aí então você vem aqui e diz a ferramenta que faz isso com Tomcat e JBoss (não vale dizer que o Capistrano faz também :P)

kicolobo:

Na sua opinião, o que virá a substituir o lugar do Java (linguagem) atualmente?

Pessoalmente, acredito que daqui pra frente Java passará a ser a ser visto cada vez menos como linguagem e mais como plataforma de execução (o que de fato sempre foi desde o início), pois estão surgindo diversas novas linguagens para a plataforma (Groovy, JRuby, Scala, Grails, etc.), ao passo que a linguagem Java, em si, já está chegando ao fim de sua própria evolução (não que a linguagem Java vá morrer, mas sim vai dar uma “estacionada”).

Pois é, o negócio é não se amarrar em nada, o Mono tá aí, correndo por fora mas do jeito que a VM deles vai e os projetos de linguagens dinâmicas na CLR comecem a dar resultados mais concretos, a concorrência vai aumentar e muito.

A questão hoje é não ficar se matando ou defendendo isso ou aquilo com unhas e dentes, mas estar preparado e de olho no futuro (e no passado também :] ) pra não perder tempo querendo apertar um parafuso a martelada.

saoj:

Como viver sem o “Open Call Hierarchy” ???

Isso me assusta um pouco. As facilidades do Eclipse para o Java, tais como auto-complete, refactoring, auto-compile, show call hierarchy, etc. agilizam muito o desenvolvimento e a manutenção de um projeto grande, cheio de classes.

Aí agente volta pra velha história do ovo e da galinha. A primeira ferramenta de refactoring refatorava o que? Smalltalk!

Bingo!

De qualquer forma, uma boa cobertura de testes sempre ajuda a simplificar esses trabalhos.

pcalcado:

Javabuntu:

** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock:

Eu não acho que Ruby o Rails vá ‘roubar a cena do java’, apesar de achar que ‘a cena do Java’ tem dias contados, mas só um exercício: você se lembra quando java chegou ao topo dessa lista? Ou quando comemoramos que Java tinha mais projetos que C+ no SourceForge? Lembra quando tudo o Brasil era Delphi, ASp e PHP e Java era ‘muito lenta, não tem boa ferramenta’, etc.?

Sinceramente, eu não sei se as pessoas esquecem ou simplesmente não viveram isso.

concerteza o java não vá durar pra sempre, assim como na área de TI nada é sustentável infinitamente… (pra comentários que houve sobre isso) só alertei pelo ponto de vista de que dificilmente o RoR vai ultrapassar o java, com as possibilidades de mercado e as metodologias ágeis de desenvolvimento cada dia ganhando mais e mais força…e o java ser muito amarrado, framework pra tudo… concerteza pouco tempo ai teremos algo tomando essa fatia de mercado…

JAVA AINDA É MAIS MERCADO, EM FAVOR DE SEU CÓDIGO ABERTO GERAR DEMANDA DE OUTRAS TENDÊNCIAS TECNOLOGICAS ATÉ ENTÃO NÃO EXPLORADA, É CERTO QUE SE HOUVER MUNDANÇAS AINDA ASSIM SERÁ SUTIL

[color=blue] O que a Sun tem feito?[/color][size=18] [/size]

No JavaOne Conference em 2006, a Sun se comprometeu em abrir o código de toda a sua plataforma Java. No dia 13 de novembro, a Sun fez a liberação inicial dos componentes de suas principais implementações:

<img src="http://petitpub.com/blog/wp-content/uploads/dukeincity.jpg" alt width="" height="">

    * Java Standard Edition (tradicionalmente executado em desktops)

  * Java Micro Edition (geralmente encontrado em telefones e outros dispositivos embutidos)

   * Java Enterprise Edition (tipicamente a base de uma infra-estrutura corporativa)

Cada uma dessas liberações ocorreu sob o GNU General Public License (GPLv2). Especificamente, a Sun abriu o código de importantes aspectos de seu Java SE (incluindo máquina virtual HotSpot, compilador javac e sistema de documentação JavaHelp) e Java ME (incluindo o código CLDC e CDL otimizado da Sun). Além disso, a empresa reiterou sua promessa de liberar todo o Java JDK em licenciamento de código aberto até o primeiro semestre de 2007.

A escolha do modelo de licenciamento para a liberação dessas implementações foi um dos aspectos mais especulados da decisão. O código do Java SE JDK foi aberto usando o GPLv2 com a exceção Classpath, e o Java ME foi liberado sob GPLv2 direto. Ao escolher o esquema de licenciamento no cerne da comunidade GNU/Linux, a Sun está buscando os desenvolvedores que, no passado, talvez não tivessem escolhido imediatamente o Java como solução. A escolha de GPL também deverá maximizar os benefícios para quem já usa código aberto, especialmente os membros da comunidade Linux.

A Sun é atualmente quem mais contribui para as comunidades de software livre e GPL.

Admite-se que a decisão da Sun de abrir o código da tecnologia Java cria potencial para implementações conflitantes da plataforma. Mas a Sun traz um valor único ao cenário do Java de código aberto, e ainda possui as implementações Java SE e Java ME padrão gold. A Sun ? como principal arquiteta da tecnologia Java e do JDK ? oferece muitos recursos para desenvolvedores e anos de experiência no equilíbrio das necessidades de um ecossistema Java complexo. Ambos contribuirão para que a Sun preserve sua função de orientar a compatibilidade da plataforma Java.

Que oportunidades o Java de código aberto cria?
Bem, agora que sabemos o que a Sun fez e por quê, vamos examinar algumas das implicações para clientes, desenvolvedores e para a própria Sun. É desnecessário dizer que as ramificações da tecnologia Java de código aberto estão se espalhando.

Para os clientes, a tecnologia Java de código aberto promete muitas recompensas. Com a abertura do código da principal plataforma para Web, os clientes adotam a tecnologia Java com plena confiança de que não ficarão presos à tecnologia ou a uma implementação. E com a tecnologia Java disponível livremente, ela estará sujeita às forças do mercado que ajudam a promover a concorrência e reduzir os preços. Além disso, com a capacidade da Sun e as comunidades Java Community Process (JCP) e Java Specification Request (JSR) para ajudar a direcionar o desenvolvimento, os custos para mudar de uma implementação Java para outra serão baixos.

A tecnologia Java de código aberto se traduz em inovação mais rápida. No mundo do código aberto, existe mais concorrência de desenvolvedores que buscam criar aplicativos de melhor desempenho e mais recursos. Isso resultará em melhores produtos, preços mais baixos e redução do custo total de propriedade. Além disso, essas mudanças serão mais tangíveis no data center ? onde a prioridade é fornecer os serviços de melhor qualidade pelo custo mais baixo ?, porque ao usar uma implementação de código aberto da tecnologia Java, os desenvolvedores terão condições de criar grandes aplicativos empresariais compostos por um custo muito menor.

Para os desenvolvedores, a tecnologia Java de código aberto oferece maior flexibilidade e a possibilidade de explorar a tecnologia Sun de maneiras novas e inesperadas. [color=black]Por exemplo, em ambientes da Web 2.0, existem muitas linguagens novas e dinâmicas (vem à mente o Ruby on Rails) que estão sendo desenvolvidas fora da Sun[/color]. A maior parte dessas linguagens é executada em seus próprios intérpretes ou máquinas virtuais.

[color=blue]Com uma máquina virtual Java de código aberto, e com a Sun e a comunidade trabalhando para acrescentar suporte a essas linguagens dinâmicas, é possível, se não provável, que a linguagem Java não seja mais a única beneficiária da máquina virtual Java. Em outras palavras, a máquina virtual Java pode se tornar uma tecnologia reutilizável que pode ser explorada em muitas linguagens diferentes. Os desenvolvedores terão a estabilidade e desempenho da máquina virtual Java, bem como a possibilidade de usá-la em seus próprios aplicativos que não são com Java.
[/color]
Por fim, o código aberto promete trazer mais desenvolvedores à comunidade de tecnologia Java, o que resultará em aumento da concorrência, mais inovação e custos mais baixos para os clientes. Vale repetir ? [size=24]O volume gera oportunidade e benefícios.[/size]

Bob Brewin
Diretor de tecnologia da Sun Software e Engenheiro Emérito Sun
Sun Microsystems, Inc.

Não entendi o que metodoloias áeis de desenvolvimento têm a ver com o tópico, e como já dissemos aqui acho que ninguém realmente acredita que Rails vai tomar todo o mercado de Java -ele vai er tomado por diversas coisas em paralelo- mas a menos que se morra em cinco anos eu acho muito difícil as coisas demorarem tanto assim. Java chegou ao status atual há apenas alguns anos e cm muita luta de uma grande comunidade, cmunidade esta que hoje em dia continua lutando por outros ideais, frutos da evolução da indústria (ou da volta no tempo se considerarmos que não ha nada de realmne novo nisso tudo).

Antes de mais nada, gostaria de dizer que, numa arquitetura distribuída, minha preferência é por usar EJB3.

O fato de EJB3 necessitar muito mais conhecimento técnico me parece uma vantagem do Spring. Afinal, o objetivo dos frameworks é diminuir o tempo que o implementador gasta com linhas de código que não resolvem o problema do negócio, certo?

Em uma aplicação Spring com ‘n’ Beans, e uma aplicação com EJB2, com a mesma quantidade de EJB’s, os descritores em XML dos EJB’s eram maiores que o XML do Spring. Eu digo por experiência própria, de ver uma aplicação sendo construída com Spring + EJB na camada de negócio. (Sim, era uma arquitetura do Bozo, aproveitando o pior de cada framework, mas isto está fora da questão aqui). Enfim, pra cada Interface de serviço, tinha um EJB, e dois beans Spring. O XML do Spring era muito menor que os vários XML de descrição dos EJB’s.

Mas enfim, na época a gente usava XDoclet tanto pra gerar o XML do Spring, quanto os descritores dos EJB’s. Mas só os descritores de EJB deixavam a equipe toda parada durante horas, de tempos em tempos, até descobrir quem tinha subido no controle de versão alguma descrição de EJB errado. O servidor de aplicação não subia mais, e não informava qual era o EJB errado. (A aplicação tinha mais de 300 EJB’s, e muita dependência entre eles).

Eu me lembro muito pouco das aulas de sistemas distribuídos na faculdade, mas me lembro que um fator fundamental era transparência de localidade. Ter duas interfaces fere este princípio. E mesmo que em alguma situação de implantação específica se queira duas interfaces, o correto seria o framework permitir o uso de duas interfaces, e não exigir. Realmente, sempre achei isso errado no EJB. Se você usar Spring na interface local, e EJB para disponibilizar a interface remota, você consegue isso.

O NetBeans 6 já trás consigo algumas facilidades neste sentido, e com certeza outras ainda virão.

Passei o sábado desenvolvendo uma aplicaçãozinha RoR com o NetBeans, pra conhecer um pouco mais os recursos que ele oferece pra desenvolvimento Ruby/Rails, e não achei ruins não.

Acho que vale a pena avaliar…

Olá Pessoal,

Visualizei muitos comentários interessantes postados até aqui.

Não sabia que o RoR pretende tomar o lugar do java…

Então,
A discussão SpringXEJB é muito mais que uma argumentação de pontos
tecnológicos… é praticamente um debate religioso. Tanto o EJB3
quanto o Spring têm pontos interessantes e atendem à determinadas situações.

Um dia a comunidade de desenvolvimento software talvez venha a entender
que a tecnologia é útil para resolver problemas tecnológicos de algum
projeto específico. Ponto. Primeiro é necessário conhecer o problema,
depois propor uma solução. Isto não pode ser invertido.

Eu tenho minhas preferências em termos de tecnologia baseado
naquilo que obtenho através da experiência, isto é, no dia a dia
descubro aquilo que é bom, pontos positivos e negativos, etc.

Todo framework e linguagem possuem pontos fortes e fracos…
Quem pode me dizer alguma solução perfeita? Se disser, está mais para uma
crença que um fator epistemológico.

Spring, EJB3, RoR nunca serão a última bolacha do pacote. Isso não existe.

Mas sobre o Spring X EJB:

Porque motivos eu preciso distribuir uma aplicação se eu nem sei se num futuro
tão próximo precisarei de tal recurso?
Usar EJB simplesmente para ter uma arquitetura n-camadas é plausível? Mesmo
que não seja distribuido? Será que é a única solução?
Ah…posso querer montar um cluster no futuro, e com EJB fica mais fácil…
Tenho que ter DI na minha aplicação? é obrigatório? vai facilitar alguma coisa?
Farei AOP? Realmente preciso ter um mentor transacional?

Pois é…tudo depende.

Sobre os argumentos do pessoal:

Concordo com o Leonardo sobre o EJB, a interface deveria ser comum. Deveria permitir
extensão e não obrigar. Gosto mais da idéia de usar um proxy para
aumentar/diminuir visibilidade.

Por enquanto é isso.

Att.,

Ou o Java acaba com o Spring ou o Spring acaba com o Java. Pode prestar atenção, as principais críticas feitas ao Java não são problemas do Java, mas sim de frameworks imbecis assim como esse Spring.

O Spring é uma aberração, uma coisa horrorosa, uma forma doentia de se trabalhar. Onde já se viu declarar toda a sua aplicação em XML? Isso nem sequer faz sentido!

Por favor elabore mais o problema com o select ao qual você fez referência. Qual é a conexão entre antigos templates de tiles e o JSF para que você deduza que eles devem funcionar perfeitamente? Complicado como exatamente?

A minha experiência com JSF é que ele é umas 100 vezes mais simples que Struts.

Me mostre aí o código simples que você tem pra carregar um select com uma entidade, postar esse valor receber um objeto do outro lado usando JSF. O meu aqui precisa de 1 converter, 1 managed bean que tenha como propriedade a lista dos objetos, mas é óbvio que eu não posso simplesmente retornar a lista de objetos, porque o meu converter vai transformar cada objeto em um número, o id do próprio objeto, então eu tenho que além de pegar a lista, ir de objeto em objeto e colocar ele dentro de um SelectItem pra poder mostrar no maldito select com um label.

Se você conhece algum jeito, ilumine a minha ignorância porque eu não sei de nenhum.

Sobre os templates do tiles, todos os projetos que eu estive envolvido desde que comecei a programar precisavam de templates padronizados e eu nunca gostei de usar includes, então logicamente o modo mais simples de se fazer isso seria usando Tiles ou SiteMesh. Se isso é uma funcionalidade tão comum, JSF deveria vir com um meio de se fazer isso por padrão, afinal deveria ser uma biblioteca pronta pra uso, não pra ficar criando extensão até pro básico, até porque Facelets existe desde que JSF se tornou “real”.

Sim, e quem liga pro Struts 1.x?

Maurício Linhares:

Me mostre aí o código simples que você tem pra carregar um select com uma entidade, postar esse valor receber um objeto do outro lado usando JSF. O meu aqui precisa de 1 converter, 1 managed bean que tenha como propriedade a lista dos objetos, mas é óbvio que eu não posso simplesmente retornar a lista de objetos, porque o meu converter vai transformar cada objeto em um número, o id do próprio objeto, então eu tenho que além de pegar a lista, ir de objeto em objeto e colocar ele dentro de um SelectItem pra poder mostrar no maldito select com um label.

Se você conhece algum jeito, ilumine a minha ignorância porque eu não sei de nenhum.

Primeiramente, converters são necessários apenas em situações especiais e não em todas. Da forma como você coloca parece que é assim toda a vida e isso o impediria de fazer algo.

Segundo, qual é a forma correta então de se trabalhar? Elabore mais o seu texto, e diga também como o JSF como um todo é “uma cagada” assim como você disse anteriormente.

Que eu saiba o com modelo de componentes é justamente para permitir que a extensibilidade do JSF. Os componentes com os quais ele foi lançado foram apenas o básico do básico para desenvolvimento web, mas sempre foi esperado que houvesse o desenvolvimento de outros por terceiros com mais funções. A sua premissa de “pronta para uso” é falsa.

Segundo, existem soluções para templates que não são “includes” de JSP, eu sei porque as uso. Mas da forma como você disse mais parece que era obrigação dos desenvolvedores deles usar justamente aquela que você deseja e nenhuma outra.

Sim, e quem liga pro Struts 1.x?

Uma boa parte do mercado que ainda pede conhecimento nessa porcaria, só. Pouca gente, né?

Então um simples select é uma situação especial? :lol:

JSF é usável quando vem com Seam, Facelets e Ajax4jsf/RichFaces/IceFaces, sem isso é uma montanha de complicações inúteis. Chega a ser engraçado ver as tags de apoio do Seam como a dos select itens e a entity converter, você olha, olha, olha e não acredita que JSF não tem isso por padrão, por mais simples que fosse fazer.

Até o próprio Craig McTananã já sabia que o negócio era complicado e já começou o Struts Shale pra ajudar os pobres desenvolvedores JSF, porque o que ele estava fazendo por fora não entrou no padrão? Porque o padrão é tão fraco? Porque o esquema de renderização de componentes ignorou por completo a possibilidade de se utlizar ajax em aplicações jsf?

Se você acha bom, ótimo, continue programando com JSF no braço, eu detesto e não indico esse suplício a ninguém.

Thiagosc:

Que eu saiba o com modelo de componentes é justamente para permitir que a extensibilidade do JSF. Os componentes com os quais ele foi lançado foram apenas o básico do básico para desenvolvimento web, mas sempre foi esperado que houvesse o desenvolvimento de outros por terceiros com mais funções. A sua premissa de “pronta para uso” é falsa.

Segundo, existem soluções para templates que não são “includes” de JSP, eu sei porque as uso. Mas da forma como você disse mais parece que era obrigação dos desenvolvedores deles usar justamente aquela que você deseja e nenhuma outra.

Foi mal, mas ASP.NET (daonde eles diziam que estavam se inspirando) já tem isso há muito tempo, isso é básico pra qualquer framework se preocupe com a camada de visualização na web. Mas voltemos a nossa premissa de “pronto pra uso”, quer dizer que o JSF não era pronto pra uso? Tinha que vir a galera pra criar extensões e deixar ele útil? Quer dizer que JSF purinho não serve pra nada?

:lol:

Tá ruim mesmo viu

Mais uma vez, e daí?

Não estamos comparando market share aqui, o que você disse era que JSF era mais simples do que Struts 1.x, o que eu estou dizendo é que o Struts 1.x deixou de ser parâmetro de comparação pra simplicidade a muito tempo, JSF tem que ser comparado com frameworks atuais como Wicket, Struts 2, VRaptor e seus contemporâneos. Struts 1.x só existe em quem deixou o trem do tempo passar ou não tem política nenhuma de atualização ou migração de tecnologias.

Só para organizar melhor a argumentação das minhas últimas mensagens:

1- As críticas do Maurício Linhares são superficiais demais. Por exemplo, não há problema algum em usar selects, ou qualquer outro componente, com datas e números. Para se adicionar um objeto qualquer criado por você mesmo é necessário fazer um converter, que consiste apenas em uma interface com 2 métodos (se me recordo corretamente, getAsObject, getAsString). O que me parece ser razoável visto que o framework não tem a obrigação de conhecer o seu modelo de classes;

2- Existem várias implementações e bibliotecas para extender o JSF. Só usa JSF “purinho” quem quer;

3- O modo de desenvolvimento do JSF é bem fácil se comparado a outros frameworks. Foge totalmente do modelo de Servlets (recebe request -> processa lógica -> repassa para outro servlet ou JSP) e se assemelha mais com desenvolvimento desktop, embora não seja a mesma coisa. Basta associar métodos e propriedades com botões, links e campos. Os ManagedBeans apenas contém esses métodos e campos. Validação e conversão também são simples;

4- Levando-se em consideração que o JSF é parte do Java EE e já conta com várias bibliotecas disponíveis e vem crescendo, se tivesse que apostar eu apostaria nele;

Eu sempre questiono os sabichões porque o JSF é odiado pelo fanáticos opensource quase como uma unânimidade, e quase sempre eles não sabem dizer o por quê.

Thiagosc:

Ou o Java acaba com o Spring ou o Spring acaba com o Java. Pode prestar atenção, as principais críticas feitas ao Java não são problemas do Java, mas sim de frameworks imbecis assim como esse Spring.

O Spring é uma aberração, uma coisa horrorosa, uma forma doentia de se trabalhar. Onde já se viu declarar toda a sua aplicação em XML? Isso nem sequer faz sentido!

Thiagosc,

Por este raciocínio, poderia-se esperar que J2EE teria enterrado Java. Foram as especificações J2EE que criaram a idéia de declarar toda a aplicação em XML.

Eu também não sou fã da extensa configuração em XML que marca a história da J2EE. Mas implementação de Spring apenas seguiu a tendência de Java de “configuration over convention”. E o Spring fez um trabalho muito melhor do que a especificação de EJB 2.1, inclusive no que se refere à verborragia em XML.
Além disso, Spring popularizou o conceito de POJOs e injeção de dependência, e convenceu o mundo Java, já que a tendência atual é valorizar estes conceitos.

Como já disseram nesta thread, cada framework tem seus méritos e seus problemas. O avanço do EJB3 se deve aos resultados atingidos pelo Spring.

Sendo assim, Spring não vai contribuir para enterrar o Java. Spring serviu para ajudar a evoluir o Java, e os conceitos de programação como um todo. Muito provavelmente Spring vai acabar antes do Java, mas ainda vai existir por algum tempo, rivalizando com a especificação, forçando a uma evolução constante da mesma, assim como o próprio Spring aprendeu com a especificação EJB 3.

Além disso, cada framework que existe foi criado para resolver algum problema do Java, o que mostra que Java e J2EE tem muitos problemas.

canabrav:

Por este raciocínio, poderia-se esperar que J2EE teria enterrado Java. Foram as especificações J2EE que criaram a idéia de declarar toda a aplicação em XML.

Eu também não sou fã da extensa configuração em XML que marca a história da J2EE. Mas implementação de Spring apenas seguiu a tendência de Java de “configuration over convention”. E o Spring fez um trabalho muito melhor do que a especificação de EJB 2.1, inclusive no que se refere à verborragia em XML.
Além disso, Spring popularizou o conceito de POJOs e injeção de dependência, e convenceu o mundo Java, já que a tendência atual é valorizar estes conceitos.

Discordo. A única coisa monstruosa que o J2EE tinha era EJB. O XML do Servlets era chato, mas era mínimo. Na época, em comparação com as opções que existiam (Perl, ASP, etc), o Java realmente era uma melhor opção.

E parem de viver no passado. Até quando usarão o EJB 2.x como exemplo?

Bom para o EJB, mas o Spring continua sendo terrível. O problema do Spring não é conceito de IoC em si, mas sim como é implementado. Parece mais uma forma de permitir que desenvolvedores Java façam coisas que em outras linguagens seria possível. Parece mais um workaround muito tosco em volta de alguma limitação da linguagem.

canabrav:

Sendo assim, Spring não vai contribuir para enterrar o Java. Spring serviu para ajudar a evoluir o Java, e os conceitos de programação como um todo. Muito provavelmente Spring vai acabar antes do Java, mas ainda vai existir por algum tempo, rivalizando com a especificação, forçando a uma evolução constante da mesma, assim como o próprio Spring aprendeu com a especificação EJB 3.

Você não entendeu o que eu quis dizer. Quando disse que o Spring acabaria com o Java, não era por causa de uma concorrência, mas sim por impor um modo de desenvolvimento tão terrível como “padrão” que automaticamente fará todos correrem para o Ruby ou Python ou qualquer outra opção que pareça sã.

Aprendamos com a Microsoft. Não precisamos de cem frameworks, precisamos apenas de um que funcione.

Thiagosc:

…
Aprendamos com a Microsoft. Não precisamos de cem frameworks, precisamos apenas de um que funcione…

Ué! Microsoft…um que funcione… de qual framework você esta falando? :twisted:

O XML da especificação servlet é mínimo? :shock: Acho que se você não usar nada da especificação, tudo bem. Mas se usar servlets, filters, eventos, taglibs, segurança, etc. tem muito XML. Mas normalmente todo mundo foge de usar muita coisa da especificação, preferindo outros frameworks, ou outros mecanismos. Talvez por isso você ache que o XML seja mínimo.

1- Você defende o JSF comparando com Struts 1.x, argumentando que ainda é muito usado no mercado. Bom, te digo que tem muita empresa ainda desenvolvendo com EJB 2.x também. E não deve parar tão cedo. Veja que ainda tem muita empresa desenvolvendo em Java 1.4

2- EJB 3 possui injeção de dependência. Se você não gosta deste mecanismo, então EJB3 também não presta. Você prefere EJB3, ou EJB2? Como você recomenda implementar sua camada de serviço em Java?

Então, você concorda que o problema está na linguagem Java. E como eu disse, Java tem muitos frameworks, porque tem muitos problemas.

Eu acredito que o melhor framework já feito em Java se chama Servlet API. Não porque seja o melhor framework para aplicações web, mas porque é bem documentado, bem testado, tem uma implementação de referencia bem-feita, tem suporte, etc. Graças a ela que esses 10 milhões de frameworks web em Java puderam aparecer.

E se você está usando muito XML você deve estar usando o framework errado. Use Stripes por exemplo que você poderá fazer tudo via annotations com a menor configuração possível.

Thiagosc:

Aprendamos com a Microsoft. Não precisamos de cem frameworks, precisamos apenas de um que funcione.

Sim, apenas uma maneira de se fazer qualquer coisa, formando uma monocultura que, quando desaba, leva todos junto com ela.
Sim, pensar de apenas uma maneira, fazendo com que você fique totalmente bitolado e que, quando precise trabalhar com outra ferramenta, se sinta completamente perdido.
Sim, apostar em apenas uma maneira de fazer tudo para que todas as aplicações criadas pela plataforma pareçam idênticas.

Sim, aí nós vamos poder seguir o mesmo caminho seguido por uma legião de programadores que trabalhavam apenas com VB6 (visto como um “único framework que funciona bem”) que, de um dia para outro, se viram totalmente abandonados e hoje estão, em sua maioria, totalmente defasados tecnológicamente por terem apostado em um “único framework que funciona bem”.

E, mais curioso ainda, usando algo que a própria criadora não usa (.net).

UOU! Quanta coisa pra “aprender” com a Microsoft!

Na minha opinião, o argumento de que você deve ter apenas um framework, e que este funcione bem, é argumento de gente que tem PREGUIÇA de aprender.

A própria Microsoft reconheceu que só WebForms não é a solução para todos os problemas e criou o Web MVC, baseado na estrutura do Rails, para o novo Visual Studio.

Eu sei que é difícil acreditar, mas eles não erram sempre. Aliás, o movimento ALT.NET está cada vez mais forte, e o novo runtime tem uma série de facilidades que estão muito à frente do que existe hoje em Java.

rubinelli:

A própria Microsoft reconheceu que só WebForms não é a solução para todos os problemas e criou o Web MVC, baseado na estrutura do Rails, para o novo Visual Studio.

Eu sei que é difícil acreditar, mas eles não erram sempre. Aliás, o movimento ALT.NET está cada vez mais forte, e o novo runtime tem uma série de facilidades que estão muito à frente do que existe hoje em Java.

Abraço

Eles contrataram o desenvolvedor do Jython para criar o IronPython, e o criador do DAL SubSonic para integrá-lo como ORM do MVC. O IronRuby ainda não chegou a uma versão estável mas também está em desenvolvimento. Java realmente tem uma cultura mais forte de compartilhar código, mas a Microsoft tem a vantagem de não depender de um processo decisório que normalmente leva anos para chegar a uma resolução.