JSF é o futuro nas empresas???

This message was edited 2 times. Last update was at 28/11/2007 23:04:43

pcalcado wrote:

xandroalmeida wrote:
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.

Ai que esta: estamos falando de solucoes web neste topico. A ferramenta certa para problema certo, lembre-se sempre

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.

pcalcado wrote:

xandroalmeida wrote: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 ?

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.

http://ruby-dbi.rubyforge.org/

Isso nao eh vantagem de Ruby, existe algo parecido para qualquer plataforma.

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.

This message was edited 3 times. Last update was at 29/11/2007 00:44:10

saoj wrote:

cv wrote:
ActiveRecord e named routes. Nao da pra implementar do mesmo jeito em uma linguagem estatica (ou que nao suporte method_missing e classes abertas).

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:

http://kore-nordmann.de/blog/why_active_record_sucks.html

http://cocoalocker.blogspot.com/2006/02/hibernate-vs-activerecord.html

Quanto a named routes, não entendi muito bem. Parece que é uma maneira de criar convenções entre URLs e respectivas actions.

Quem quiser tentar entender:

http://wiki.rubyonrails.com/rails/pages/NamedRoutes

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...

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 -

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Community/Composition%20on%20Rails&

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.

[]'s

Kenobi

Kenobi wrote:
- 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.

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.

Kenobi wrote:
- Suporte à JPA e seus diversos providers, não limitando à uma única implementação, ActiveRecord. Diga-se de passagem gosto bastante do GORM.

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?

Kenobi wrote:
- Integração com o framework de segurança Acegi, que é um dos melhores do mercado.

JRuby on Rails?

Kenobi wrote:
- AOP, para retirar interesses ortogonais do seu código, ou outras aplicabilidades.

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.

Kenobi wrote:
- Suporte ao Compass, framework de buscas que encaspula ferramentas ORM também , fazendo uso do Lucene, um excelente indexador.

Você pode usar Lucence como servico para Ruby. Alias, para qualquer coisa. Da ma olhada nos projetos paralelos do Lucene.

Kenobi wrote:
- Suporte à Laszlo , entre outros frameworks para Ajax, como DRW, Dojo e por aí vai ...

Qual o problema do AJAX do Rails?

Ants de contiuar respondendo por favor leia isso:

http://wiki.rubyonrails.com/rails/pages/Plugins

Para conhecer uma das extensões disponíveis.

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.

O mundo da volta, da volta e para no mesmo lugar.

BTW:

http://martinfowler.com/bliki/GroovyOrJRuby.html

JavaEvangelist Membro desde: 26/04/2005 11:18:25 Mensagens: 469 Offline

saoj wrote: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...

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.

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.

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.

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?

Por que particularmente não acho o ActiveRecord tão poderoso quanto um Hibernate por exemplo, sistema de LazyLoad - reattachment.

JRuby on Rails?

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.

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.

O mesmo se aplica ao Groovy, que sua MOP é bastante robusta, entretanto você poderá aproveitar esse ponto de extensibilidade, para instrumentação por exemplo.

É integrado ao Rails ? Ao Grails vem prontinho pra uso ....

Qual o problema do AJAX do Rails?

Nenhum, só comentei que o Grails também possui tal suporte e a outros frameworks do mundo Java, como Laszlo.

Ants de contiuar respondendo por favor leia isso:

http://wiki.rubyonrails.com/rails/pages/Plugins

Para conhecer uma das extensões disponíveis.

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.

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.

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.

Ae galera, estava procurando algo sobre Seam vs Rails e achei um debate bem legal. Leiam principalmente os comentários , por favor :

http://jroller.com/obie/entry/seam_aims_for_ruby_on

Kenobi wrote:
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.

Qual tipo de abordagem, Domain Model? Leia meu post novamente: você deve colocar regras de negócio no model em Rails

Kenobi wrote:
E já vi diversos projetos Rails por aí, e isso não ocorre. Na maior parte deles, o negócio fica mesmo nas Actions.

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?

Kenobi wrote:
Por que particularmente não acho o ActiveRecord tão poderoso quanto um Hibernate por exemplo, sistema de LazyLoad - reattachment.

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.

Kenobi wrote:
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.

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.

Kenobi wrote:
Mais um ponto, já comentei sobre o JRuby anteriormente e ainda acho que não é uma plataforma madura suficiente para projetos sérios.

É sua opinião, eu a respeito mas isso não faz dela verdade.

Kenobi wrote:
A Oracle contratou a TW para suprir um problema sério de performance, por exemplo e isso tem pouquíssimas semanas.

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í?

Kenobi wrote:
O mesmo se aplica ao Groovy, que sua MOP é bastante robusta, entretanto você poderá aproveitar esse ponto de extensibilidade, para instrumentação por exemplo.

Então por que você colocou AOP como um onto nessa discussão?

Kenobi wrote:É 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.

Então é hora de reler a boa e velha documentação. Suas respostas estão lá.

Kenobi wrote: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.

"Legado sólido" é Java, né? Pois é, legado sólido era C++ também. E COBOL também. Pois é.

JavaEvangelist Membro desde: 26/04/2005 11:18:25 Mensagens: 469 Offline

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)

saoj wrote:

cv wrote:ActiveRecord e named routes. Nao da pra implementar do mesmo jeito em uma linguagem estatica (ou que nao suporte method_missing e classes abertas).

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.

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?

Kenobi wrote:Mais um ponto, já comentei sobre o JRuby anteriormente e ainda acho que não é uma plataforma madura suficiente para projetos sérios.

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?

Kenobi wrote:A Oracle contratou a TW para suprir um problema sério de performance, por exemplo e isso tem pouquíssimas semanas.

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.

Kenobi wrote: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.

Por "legado solido" vc diz dezenas de milhares de sistemas usando Struts 1.x e EJB 2? Hmm... solido e marrom, ne?

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

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.

Leonardo3001 wrote: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.

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.

Leonardo3001 wrote:
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.

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.

Leonardo3001 wrote:
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.

Acho que vou escrever sobre iso amanha. Sao 23:35 em Oz e eu acabo de chegar do bar

Qual tipo de abordagem, Domain Model? Leia meu post novamente: você deve colocar regras de negócio no model em Rails

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.

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?

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.

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.

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%.

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.

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.

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.

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.

É sua opinião, eu a respeito mas isso não faz dela verdade.

Concordo e espero que em pouco tempo eu reveja essa posição, dada à equipe do JRuby que é muito competente.

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í?

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.

Então por que você colocou AOP como um onto nessa discussão?

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.

Então é hora de reler a boa e velha documentação. Suas respostas estão lá.

Unf ?!

"Legado sólido" é Java, né? Pois é, legado sólido era C++ também. E COBOL também. Pois é.

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.

Notícias, artigos e o maior fórum brasileiro sobre Java