[quote=pcalcado][quote=Kenobi]Bom shoes, sinceramente não acho Rails ou frameworks ActionBased interessantes para cenários onde componentes ricos são usados intensamente.
Ter um componente pronto e otimizado, facilita muito a vida da equipe que vai apenas reutilizar o mesmo.
Minha aposta para componentes está no Flex ou Silverlight, por uma série de outras razões, começando pela possuibilidade de utilizar richmedia.
[/quote]
Eu nao falei que as aplicacoes sero feitas com MVC action-based e sm que Rails ja mudou a forma dos frameworks web.
Agora enquanto Silverlight, Flex e JavaFX forem mutuamente exclusvos eu nao apostaria meu futuro neles. Alias em Silverlight (que eu ja conheci bastante de uma antiga parceria com a Microsoft) eu nao dependeria ate ele ser refeito.[/quote]
O flash não é um padrão e detém mais de 90% do marketshare para richmedia.
Particularmente aposto muito no Flex ou Laszlo, plataformas que exportam para a engine.
Se olharmos para a contra-partida - HTML + JavaScript, isso nunca foi e nunca será uma solução … gambiarra das feias e está aí até hoje …rss
[quote=pcalcado][quote=xandroalmeida] RoR é legal, é sexy (tem gente que acha isso, meu conceito de sexy é outro, mas vamos lá), trouxe idéias legais e finalmente deu voz à simplicidade.
Mas eu tenho a impressão que alguns simplesmente estão falando: "Cara, Java é passado junto com Cobol, agora para ser legal e moderno tem que ser RoR. "
Não quero dizer que não devemos usar RoR, devemos sim, até mesmo para saber como funciona e usara suas boas idéias. Mas a plataforma Java, com todos seus defeitos, esta a anos luz à frente de RoR. Onde estão as aplicações Enterprise em RoR? Twitter ? (Olhe o preço que eles tiveram que pagar para escalar)
[/quote]
Nao sei o qe vce chama de ‘enterprise’ mas talvez olhar a pagina de clientes da 37Signals e da ThoughtWorks pode te ajudar. Alias, entra em um site de empregos e faz uma busca or vagas.
[/quote]
O termo enterprise não foi bom, mas o que eu quis dizer solução para grandes problemas, aplicações críticas, que envolvam transações financeiras, billing, ERPs. Um software tão completo, que por acaso é uma IDE, como é o eclipse, e mais outros exemplos que não vou me lembrar neste momento. Estes tipo de aplicações que não são tão “sexy”.
Não vamos pensar que o mundo de softwares limita-se a aplicações web. E mesmo em muitas aplicações que só parecem web exigem muitos processos “pesado” e complexos no back end.
Java pode não ser bom para tudo, mas ele é muito bom para muitas coisas.
Quanto à pesquisa de vagas não vou poder ver agora para poder falar alguma coisa, mas fico curioso e mais tarde vou pesquisar isso.
O que dizer é que se Ruby não rodasse na JVM ele nem drivers decente para bancos de dados iria ter (rodando na JVM ele pode usar o JDBC). Quantos SGBD tem drivers para o Ruby ? Como fica a comparação do Hibernate vs ActiveRecords ?
E quanto tempo iria levar para Ruby ter um Virtual Machine da qualidade de JVM?
Foi mais ou menos isso foi minha pergunta.
Eu não disse que qualquer sistema deve ser feito em Java, que Java aguenta quaquer sistema. Eu já trabalhei em sistema que Java abriria o bico em milisegundos =) Já trabalhei em sistema que Java foi usado como um canhão para matar um mosca.
Acho que neste ponto eu não discordo em nada com você.
De maneira alguma eu acho que RoR não deva ser usado, como eu falei, acho que ele trouxe boas idéias, faz coisas interessante, mas como Java, não é a solução simples para qualquer problema complexo.
A razão de eu me meter nesta conversa, com um grande risco de tomar porradas :-), foi a minha impressão de que as vezes o Java é posto como grande vilão e RoR é o nosso grande salvador.
Acho que RoR é mais ferramenta em nossa caixa de ferramentas.
[quote=Kenobi]
O flash não é um padrão e detém mais de 90% do marketshare para richmedia. [/quote]
Quantos concorrentes (de verdade) Flash teve nos ultimos 10 anos? Sera que isso nao eh consequencia?
Agora me responda dai do seu Mac este texto que eu estoue screvendo no meu Mac: quanto tempo o Windows ficou sem concorrentes reais? Voce apostaria tudo em desenvolvimento Windows-only hoje?
Concordo mas acho que as opcoes de rich media nao ficam atras. O problema eh intrinseco ao ambiente web, creio.
Ai que esta: estamos falando de solucoes web neste topico. A ferramenta certa para problema certo, lembre-se sempre
[quote=xandroalmeida]O que dizer é que se Ruby não rodasse na JVM ele nem drivers decente para bancos de dados iria ter (rodando na JVM ele pode usar o JDBC). Quantos SGBD tem drivers para o Ruby ? Como fica a comparação do Hibernate vs ActiveRecords ?
[/quote]
Acho que voce esta um pouco confuso pela plataforma Java. Driver especifico para uma plataforma soh eh necessario quando a plataforma possui limitacoes ou quando quer. Java tem limitacoes que te fazem JDBC a melhor opcao quase sempre mas outras plataformas como Ruby nao dependem disso. Ruby pode utilizar os drivers nativos disponiveis em qualquer banco de dados meia-boca.
O Java oferece Hibernate, iBatis, JPA, JDO etc. para soluções de ORM. E temos também o JDBC que está bem maduro com a maioria dos bancos suportando muito bem. Temos tb alguns bons pool de conexões como DBCP e C3P0.
Já ouvi falar que ActiveRecord é um dos pontos onde RoR é bastante criticado. Mas tudo bem. Hibernate tb não agrada a todos e para isso que tem iBatis, JDBC e outras alternativas. Segue alguns links:
Essas são as principais funcionalidades que temos em Ruby e não podemos ter em Java?
Veja bem. Não estou falando que Ruby on Rails é ruim. Só estou querendo entender as reais necessidades que justificariam abandonar Java e partir para o Ruby em termos de framework web. Ficou claro que outras pessoas aqui possuem esse mesmo questionamento…
Acho que não custa fazer algumas experiencias com o RoR. Não nego que tem idéias muito boas ali. Só peço que, por favor, não comparem com JSF ou Struts, pois aí é covardia com o pobre Java…
[quote=pcalcado][quote=xandroalmeida]
Não vamos pensar que o mundo de softwares limita-se a aplicações web. E mesmo em muitas aplicações que só parecem web exigem muitos processos “pesado” e complexos no back end.
[/quote]
Ai que esta: estamos falando de solucoes web neste topico. A ferramenta certa para problema certo, lembre-se sempre
[/quote]
Bem lembrado, sai do tópico mesmo do assunto. Mas eu tinha que falar. hehehe
Só para não ficar muito off.
Acho a solução JSF complexa demais, nisso eu concordo plenamente que a solução RoR é muito melhor.
Acho que voce esta um pouco confuso pela plataforma Java. Driver especifico para uma plataforma soh eh necessario quando a plataforma possui limitacoes ou quando quer. Java tem limitacoes que te fazem JDBC a melhor opcao quase sempre mas outras plataformas como Ruby nao dependem disso. Ruby pode utilizar os drivers nativos disponiveis em qualquer banco de dados meia-boca.
Isso nao eh vantagem de Ruby, existe algo parecido para qualquer plataforma.
[/quote]
Bem, só vou continuar este ponto, porque o resto acho que estamos de acordo.
Este talvez seja um ponto que eu não concordo. (e lá vou eu sair do tópico de web novamente)
Não enxergo a existencia do JDBC por uma falha da plataforma Java. Pode-se ter uma implementação propietaria puramente em Java ou um bind para a api em C do driver nativo. Existe isso? Não me lembro de ver algum, então acredito que o Jdbc dê bem a conta do recado.
Eu sei que pode-se atacar o Jdbc por ser uma padronização e padronização podem ser ruins porque deve-se padronizar pelo mínimo comum. Mas acho que a Sun e a JCP fizeram bem o seu trabalho e não tem-se dúvidas que o acesso a Base de dados em Java é fácil, rápido e confiável.
Quem programou em C sabe o porre que é cada base de dados ter sua api. Já programou usando a OCI do Oracle? Aquilo é quase como programar GUI em Win32.
Bem, já escrevi muito off neste tópico sobre interface Web.
Esse nao eh o problema. DBI (que eu linkei acima) oferece padronizacao, um driver JDBC nao eh apenas uma maneira padronizada é uma forma de lidar com o fato que Java é multiplataforma e não pode depender do SO.
Java nao pode contar com o driver instalado no servidor (a menos naquele JDBC-ODBC horrivel) entao o fornecedor tem que prover seu proprio driver para JDBC. Outras plataformas geralmente nao precisam de um driver proprio.
[quote=saoj][quote=cv]
ActiveRecord e named routes. Nao da pra implementar do mesmo jeito em uma linguagem estatica (ou que nao suporte method_missing e classes abertas).
[/quote]
O Java oferece Hibernate, iBatis, JPA, JDO etc. para soluções de ORM. E temos também o JDBC que está bem maduro com a maioria dos bancos suportando muito bem. Temos tb alguns bons pool de conexões como DBCP e C3P0.
Já ouvi falar que ActiveRecord é um dos pontos onde RoR é bastante criticado. Mas tudo bem. Hibernate tb não agrada a todos e para isso que tem iBatis, JDBC e outras alternativas. Segue alguns links:
Essas são as principais funcionalidades que temos em Ruby e não podemos ter em Java?
Veja bem. Não estou falando que Ruby on Rails é ruim. Só estou querendo entender as reais necessidades que justificariam abandonar Java e partir para o Ruby em termos de framework web. Ficou claro que outras pessoas aqui possuem esse mesmo questionamento…
Acho que não custa fazer algumas experiencias com o RoR. Não nego que tem idéias muito boas ali. Só peço que, por favor, não comparem com JSF ou Struts, pois aí é covardia com o pobre Java…[/quote]
Acho que essa comparação JSF ou Struts com o Rails não faz muito sentido, pq ambos resolvem somente uma parte do problema.
Seria interessante uma comparação entre Rails e Seam, por exemplo, para medir desde arquitetura à possibilidades de extensibilidade, performance e tudo mais … aí sim iria ser uma comparação mais justa, e outra, vou comprar uma briga aqui com o pessoal de Rails.
Entnrado nesta briga, existe o Grails que é baseado em java e diversos projetos de respaldo e na minha opinião superior.
Citem três motivos técnicos para me fazerem trocar Grails por Rails… para não ser injusto, vou citar alguns :
Camada de negócios desacoplada e injetada (IOC-Spring), retirando aquele código de negócio engruvinhado das Actions, que já foi ponto de discussão durante anos por diversos que abordam Design Patterns.
Suporte à JPA e seus diversos providers, não limitando à uma única implementação, ActiveRecord. Diga-se de passagem gosto bastante do GORM.
Integração com o framework de segurança Acegi, que é um dos melhores do mercado.
AOP, para retirar interesses ortogonais do seu código, ou outras aplicabilidades.
Suporte ao Compass, framework de buscas que encaspula ferramentas ORM também , fazendo uso do Lucene, um excelente indexador.
Suporte à Laszlo , entre outros frameworks para Ajax, como DRW, Dojo e por aí vai …
Uma coisa interessante é que ele é baseado nos mesmos preceitos do David Heinemeier, tornando sua produtividade excelente.
Não tiro o mérito do Rails, principalmente do David e o Grails é uma cópia desses paradigmas. Entretanto, sua implementação é feita de maneira que me agrada muito, principalmente vindo do mundo java, já que de fato o JRuby está se tornando uma das melhores alternativas para o Rails.
Empresas como JetBrains entre outras estão começando a apostar no framework. A SAP com seu programa para Rails, estendeu ao Grails visando também esse público que está crescente -
Só para findar, alguns dos citados fazem uso de frameworks concebidos no meio Java, com uma qualidade assegurada por alguns anos e excelente performance, oriunda de linguagens estáticas. Reutilizar esse conhecimento de maneira rápida é o que torna interessante e aderente aos paradigmas do David.
AHM!? De que voce esta falando? Em Rails as regras de negoco ficam nos models, que podem muito bem ser m domain model bonitinho. Alias a maoria dos rojetos que eu ja vi em Java (basta navegar pelo forum) cloca regra de negocio em tudo quanto eh luar menos no objeto de negocio.
Existem alternativas ao ActiveRecord mas por que exatamente você precisaria de algo diferente? No mais, se você precisa dos frameworks mais poderosos que tal JRuby on Rails?
JRuby on Rails?
Uhm… se voê estudar um ouquinho sobre Ruby vai perceer que boa parte do que AOP faz nao é necessário numa linguagem dinâmica. O fato de "sentir falta de AOP em Rails"aliás me mostra que seus pontos são influenciados por você não entender como Ruby se comporta no desenvolvimento de aplicações e orque alguns dos seus pontos simplesmente não são aplicáveis.
Você pode usar Lucence como servico para Ruby. Alias, para qualquer coisa. Da ma olhada nos projetos paralelos do Lucene.
Engraçado essa coisa do Java ser o pau pra toda obra. Me lembra quando comecei com Java e tinha que convencer toda uma empresa que nem tudo precisava ser feito em C++. Isso foi entre 90 e pouco e 2003. Agora a historia se repete.
[quote=saoj]Veja bem. Não estou falando que Ruby on Rails é ruim. Só estou querendo entender as reais necessidades que justificariam abandonar Java e partir para o Ruby em termos de framework web. Ficou claro que outras pessoas aqui possuem esse mesmo questionamento…
Acho que não custa fazer algumas experiencias com o RoR. Não nego que tem idéias muito boas ali. Só peço que, por favor, não comparem com JSF ou Struts, pois aí é covardia com o pobre Java…[/quote]
Covardia é ainda empurrarem esses frameworks goela abaixo da maioria dos programadores.
Ninguém precisa abandonar o Java. Aliás, Ruby é uma péssima linguagem do ponto de vista do típico arquiteto Java. Ruby dá poder ao programador. Só pra te dar uma idéia do tipo de coisa que um programador pode fazer em Ruby, no ActiveRecord você pode escrever algo como Agent.find_by_name(‘Jack Bauer’) e receber . Se você abrir a classe Agent, vai ver que não há nenhum método find_by_name. O que acontece é que a classe base dos modelos captura as chamadas find_by_ que não encontraram nenhum método correspondente (o que seria simplesmente uma Exception no Java) e cria a query na hora. Outro exemplo: os desenvolvedores do Rails resolveram adicionar uma série de métodos às classes principais do Ruby, como capitalize e pluralize em String.
Bom, particualrmente não acho saudável esse tipo de abordagem, mesmo porquê em muitos cenários de negócio você vai ter composição com diversos objetos de domínio. Poder descoplar e transformar esse negócio em um EJB3 por exemplo, é um ponto de extensibilidade para FailOver por exemplo.
E já vi diversos projetos Rails por aí, e isso não ocorre. Na maior parte deles, o negócio fica mesmo nas Actions.
Por que particularmente não acho o ActiveRecord tão poderoso quanto um Hibernate por exemplo, sistema de LazyLoad - reattachment.
Fanatismo, pois se existem outras soluções que contemplam tal problemática, pra que ter um custo adicional de desenvolvimento ? Vai contra os princípios do David, por exemplo.
Mais um ponto, já comentei sobre o JRuby anteriormente e ainda acho que não é uma plataforma madura suficiente para projetos sérios.
A Oracle contratou a TW para suprir um problema sério de performance, por exemplo e isso tem pouquíssimas semanas.
O mesmo se aplica ao Groovy, que sua MOP é bastante robusta, entretanto você poderá aproveitar esse ponto de extensibilidade, para instrumentação por exemplo.
Você pode usar Lucence como servico para Ruby. Alias, para qualquer coisa. Da ma olhada nos projetos paralelos do Lucene.
É integrado ao Rails ? Ao Grails vem prontinho pra uso …
Nenhum, só comentei que o Grails também possui tal suporte e a outros frameworks do mundo Java, como Laszlo.
Só um comentário, conheço a parte de plugins de Rails e também conheço o framework, já fiz alguns desenvolvimentos com Rails/Ruby.
A questão não é java pra toda obra, e sim Groovy e Grails , utilizando estrutura pré-existente. Você vai continuar com os preceitos do David, mas se baseando num legado sólido.
Qual tipo de abordagem, Domain Model? Leia meu post novamente: você deve colocar regras de negócio no model em Rails
Não seja por isso: em quase dez anos eu já vi muitos projetos em Java e as regras de negócio quase nunca estavam onde deveria. Qual o ponto?
Se você precisa de algo mais poderoso use algo mais poderoso. Agora eu realmente duvido que muitas aplicações precisem. Usamos porque é assim que sempre foi. O bom arquiteto sabe avaliar estas coisas.
Você critica algo que nem cnhece para defender Java e o fanático sou eu? Pelo contrário: ferramenta certa para problema certo, seja Java Ruby C# ou o que for.
Eu apenas dei a opçõ de usar o que você citou em Rails. Obviamente se você dá mais importância a isso num dado projeto do que às vantagens que Rails te daria é besteira mas geralmente quem desenvolve com Rails o faz pelas vantagens do framework. Minha opção foi juntr as duas coisas boas num ponto único.
É sua opinião, eu a respeito mas isso não faz dela verdade.
Eu já trabahei em elo menos 3 projetos que rpecisaram contratar a Sun para consertar caca na JVM. Aliás, péssimo suporte, um amigo meu teve que consertar o erro na JVM ele mesmo e depois nem pudemos usar o fix por causa das malditas licencas. E daí?
Então por que você colocou AOP como um onto nessa discussão?
[quote=Kenobi]É integrado ao Rails ? Ao Grails vem prontinho pra uso …
Nenhum, só comentei que o Grails também possui tal suporte e a outros frameworks do mundo Java, como Laszlo.
…
Só um comentário, conheço a parte de plugins de Rails e também conheço o framework, já fiz alguns desenvolvimentos com Rails/Ruby.
[/quote]
Então é hora de reler a boa e velha documentação. Suas respostas estão lá.
“Legado sólido” é Java, né? Pois é, legado sólido era C++ também. E COBOL também. Pois é.
Realmente, agora que Groovy está amadurecendo e deixando de ser “Java com umas pitadas de Ruby”, está ficando bem legal. Aquelas closures de ExpandoMetaClass são o bicho pra criar DSLs sem poluir o namespace, o operador ?. é uma excelente sacada, e tipagem estática opcional é um diferencial que o Ruby poderia incorporar. Mas eu estou cansado de ver gente falando “a gente não precisa de Rails porque tem o Grails”, e aí virar para o lado e fazer projeto em JSF + JPA. (ou, infelizmente, Struts 1 + DAO)
O Java oferece Hibernate, iBatis, JPA, JDO etc. para soluções de ORM. E temos também o JDBC que está bem maduro com a maioria dos bancos suportando muito bem. Temos tb alguns bons pool de conexões como DBCP e C3P0.[/quote]
Voce perguntou o que tinha no Ruby on Rails que nao dava pra fazer em Java. Nao o que tinha no Rails que nao dava pra fazer mais ou menos parecido em Java. Eu afirmei que uma implementacao pau-a-pau do ActiveRecord eh impossivel em uma linguagem como Java ou C# 2.0, e vc me vem com uma lista de possiveis mais-ou-menos-quem-sabe-tomando-mais-um-LSD-fica-parecido? :?
E no que vc se baseia pra afirmar isso, mesmo tendo o Mingle e o Oracle Mix como prova de que o JRuby on Rails pode ser usado para projetos serios?
A Oracle nao contratou a TW pra “suprir um problema serio de performance”, como vc alega. A Oracle contratou a TW para ajudar a desenvolver o Mix.
Eu sei pq eu ajudei a escrever a porra da proposta, entao cuidado nas especulacoes
As otimizacoes de performance estavam inclusas no trabalho, como em todo projeto que vai pra producao; testes de performance sao parte da suite de testes de aceitacao da grande maioria dos projetos da TW. E nao sei de onde vc tirou que o Mix tinha problemas “serios” de performance: o JRuby tem se comportado tao bem que eles nem se importaram em ligar o fragment caching ainda. O Mix em si mal foi otimizado, foi so resolver uns probleminhas no proprio JRuby e os resultados foram, IMNSHO, excelentes.
Por “legado solido” vc diz dezenas de milhares de sistemas usando Struts 1.x e EJB 2? Hmm… solido e marrom, ne?
Uma coisa que fiquei o dia inteiro quebrando a cabeça: lá atrás o Shoes disse que dá pra fazer um domain model bonitinho na camada model. Acredito, mas parece que teria que abandonar um pouco o ActiveRecord porque aquela classe Base comum a todas as classes impede a utilização de um relacionamento de herança. E se as tabelas das bases de dados forem bem “antinormalizadas”, o ActiveRecord pode ser uma péssima idéia. O jeito, óbvio, seria, ou partir pro Hibernate em Java, ou queries à mão em Ruby.
Tem também o problema de que nem o JRuby on Rails, nem os frameworks Java tem integração entre si. Por exemplo: será que o Spring vai injetar as classes “legadas” em Java nas novas classes escritas em JRuby? Pode até ser que devessemos utilizar “soluções de contorno” para que as duas linguagens conversem entre si, mas a classe Ruby não ficaria muito elegante. Pode até ser que se devesse escrever tudo em Ruby mesmo, mas o cliente não vai pagar a reescrita de código em outra linguagem.
Tudo bem que o Shoes falou que cada caso é um caso. Mas atualmente eu vejo que o Rails exige tantas precondições, que não me faz sentir tanta confiança nele.
Leonardo, acrdito que o problema é que você escreve Ruby mas pensa Java. Me dê um caso onde heranca seja a única ou mesmo a melhor oção d cuk typing ou mixins nao resolve.
Para o caso espec[ifico do Spring segundo os fornecedores o framework oferece suporte. Pro rest é só ver como acontece integração com outras linguagens.
Não se enganem, enquanto tem gente questionando se vale a pena ou não usar a Sun e as outras grandes já estão despejand dnheiro em linguagens de JVM há muito tempo.
[quote=Leonardo3001]
Tudo bem que o Shoes falou que cada caso é um caso. Mas atualmente eu vejo que o Rails exige tantas precondições, que não me faz sentir tanta confiança nele.[/quote]
Acho que vou escrever sobre iso amanha. Sao 23:35 em Oz e eu acabo de chegar do bar
Novamente não acredito como sendo uma prática bacana e pelo blog do Gavin King, ele também não acha , até mesmo porque o Seam tem esse fundamento, de separação de negócios.
Você há de concordar comigo que os profissionais java ao decorrer desses anos amadureceram no quesito design. Hoje em dia ver um sistema com regras de negócio em Actions feito em Java é bem mais raro, ou o profissional é muito iniciante.
Acho que o Rails introduz um retrocesso, pois muitos programadores vão começar a história tudo denovo.
Extamente por isso e pensando em extensibilidade,papel do arquiteto como mencionado, é que busco uma solução mais abrangente, afinal o business plan de algumas companhias pode supreender.
Já peguei casos como a GE , que sua aplicação de Auto-Finance estava projetada para um crescimento de 30% ao ano e na prática foi mais de 168%.
O que você chama de ferramenta certa, me limitando ao Rails e não linguagens ? Qual o target ? Pequenos projetos startups ?
O ponto que sou favorável ao Grails é o subsídio ao crescimento dessa Startup. E não estou falando em Java aqui e sim Groovy.
Foi o que levantei sobre os preceitos do David para aplicações Web, que são seguidas pelo framework Grails. Dê uma lida no meu post anterior com mais cuidado.
Concordo e espero que em pouco tempo eu reveja essa posição, dada à equipe do JRuby que é muito competente.
Daí que estava falando sobre alguns problemas que a plataforma ainda vai enfrentar, por ser muito nova e investir pesadamente nisso é um risco a ser considerado.
Ponto de extensibilidade novamente. Soluções criadas como Log proprietário, utilizadas em outras aplicações, poderão ser acrescidas de forma prática e rápida.
Unf ?!
Esse aqui é um ponto interessante de discussão.
Vou começar pela evolução da plataforma e linguagem. Java não está sentado parado esperando o trem passar. Muitas iniciativas vem sendo incorporadas à cada versão, o que nos torna um pouco mais aderentes à realidade atual , quando comparados aos que você citou. Entretanto, voltando aos legados, C++ possui uma consistência sólida em alguns universos, tanto que o pessoal que desenvolve Games, utiliza intensivamente até os dias atuais e não cogita trocar tão cedo de linguagem para as suas engines. Lua pode vir para alguns casos, scripts, mas o core na maior parte dos casos é C++.
Este exemplo, retrata o que penso sobre Java para ambientes de integração e Web. Há muita coisa de qualidade e substituir sem ter algo à altura é complicado.
Cobol é o retrato da linguagem que não acompanhou a evolução. Uma das features mais bacanas das linguagens dinâmicas Groovy e Ruby são Closures, e a comunidade Java está atenta, com propostas para incorporar tal funcionalidade à linguagem - http://www.javac.info/consensus-closures-jsr.html
Para findar, não sou xiita e gosto muito de Ruby e principalmente sua sintaxe. Acontece que o Java hoje me provê de uma infra-estrutura bastante abrangente, como MDB´s por exemplo, utilizados em larga escala para integração, frameworks para concorrência (http://www.infoq.com/news/2007/11/jppf-1.0) .
Esse tipo de infra, para se construir do zero numa nova linguagem/plataforma, onera bastante tempo e custos.
