Lançada a versão final do Grails 1.0

Assuntos Gerais Notícias
#1

É com satisfação que vejo a evolução do Grails, e que agora chega a sua versão 1.0 e com site novo. Vejam as novas features:

[quote]
New Features

* GORM features ORM DSL for advanced Mappings
* Support for easy to use Filters
* Content Negotiation support
* REST support
* JNDI Support

New Features
ORM DSL

Grails 1.0 RC1 introduces an Object Relational Mapping (ORM) Domain Specific Language (DSL) that reduces the need to fallback to traditional Hibernate mapping. The DSL allows customization of the following aspects:

* Table and column names
* Inheritance strategy
* Second-level cache configuration
* Id generation strategy
* Composide Id support
* Eager/Lazy loading
* Database indices
* Custom Hibernate user types[/quote]

Mais informações em: http://www.grails.org/

Bons códigos

#2

O Grails é realmente incrível, sendo possível criar uma aplicação CRUD com poucos (3 ou 4) comandos. O Gorm também está muito legal, é facílimo de fazer os mapeamentos, e tem por base nada mais nada menos do que o Hibernate, provavelmente o framework de ORM java mais maduro de hoje.

Parabéns a equipe do Grails!

:wink:

#3

Alguém conhece algum site ou projeto importante desenvolvido usando o Grails?

#4

Duvido que muitas empresas tenham apostado no Grails antes da versão 1.0. Mas sei de um case, a SAP:

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Community/Composition+on+Grails

Mas agora vão aparecer outros. Grails facilita muito o desenvolvimento em Java e duvido que as empresas que trabalham na plataforma não abram os olhos para este framework.

#5

Grails is like Rails?

#6

Já que vi que o pessoal anda “incendiando” tanto sobre Ruby X Java, queria saber de quem é mais experiente:

O que ainda não dá pra fazer em Grails que dá pra fazer em Rails?
O que Ruby ainda faz que Groovy não faz?

Espero que o pessoal que conheça bem o Groovy e Grails ajude a debater esta situação.

Abraços

#7

Até onde eu mexi nele, eu diria que sim. Tem facilidades espantosas, como Rails. Só que ele faz uma camada sobre Hibernate e Spring, o que não acho nem um pouco má idéia :smiley: .

#8

O maior problema de Groovy é que ela é próxima demais do Java, então muita coisa não tem como ser feita em Groovy, como mixins, definir novos métodos em tempo de execução (na verdade, até pode se você fizer umas gambis no despacho de métodos, mas é bem mas complicado do que seria em Ruby com um class_eval, module_eval ou ainda um define_method).

Não vi callbacks pra quando uma classe extende a outra (e isso é muito importante pra metaprogramação e seria ainda mais se Groovy tivesse suporte a módulos). Groovy também não tem open classes/modules, deixando você alterar o comportamento de classes já definidas no ambiente (como colocar novos métodos em String). Open classes são uma mão na roda quando voc está mexendo com código alheio que está versionado e você não pode fazer “patches” diretos.

Enfim, o grande problema de Groovy hoje ainda é o suporte fraquinho a metaprogramação e é isso que faz de Ruby uma linguagem bem mais flexível.

#9

Mauricio, obrigado pelas respostas. Estou pesquisando sobre Groovy e é interessante saber o que ele pode ou não ter. Vi que Groovy tem a proposta para Mixins. Alguns também estão fazendo o mesmo para Open Classes. Bom, por enquanto não é oficial, então, Ruby ainda está na frente.
Mas JRuby ainda é lento para uma JVM. Aliás, não sei se fui só eu, mas constatei que JRUby roda bem no GlassFish e lentamente no Tomcat. Há alguma constatação quanto a isso ou foi só comigo?

Abraços

#10

Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008 :slight_smile:

#11

[quote=kicolobo]Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008 :)[/quote]

Oi Kico,
Acho que você se confundiu quando falou “Grails tem uma coisa que o Ruby”.Grails é um framework, ruby é uma linguagm.

Da última vez que eu parei pra olhar o rails 2 não funcionava com jruby, mas existe uma galera usando o rails “antigo” com jruby (tem até livro: http://www.apress.com/book/view/1590598814).

O código legado pode ser usado com jruby também (google: java jruby integration), não sei até que ponto a coisa funciona. Onde bytecode é o denominador comum não devem ocorrer problemas.

HSQLDB embutido é uma grande vantagem?

Eu não conheço nada de Groovy, mas levando em conta o que o Mauricio falou, juntando com o que o mercado vem apresentado, jruby deve estar num andar a cima.

#12

O JRuby 1.1R… funciona com Rails 2.0.2 sim. Abaixo acho que 1.0.3, se num me falha a memória.
JRuby é muito bom, mas tem a grande falha: lento. Muito mais lento que Groovy, e isso que irrita nele. Rails no GlassFish é lento, mesmo que mais rápido que no Tomcat. Grails é beeeeeeeeeeeem mais rápido. Claro que JRuby vai evoluir, mas até lá, pode ser que Groovy tb tenha evoluído, e muito.
Embora eu goste da sintaxe do Ruby, tenho que ver bem o Groovy, uma vez que o Grails possui uma facilidade gigantesca no desenvolvimento, coisa que ainda não havia visto em frameworks para a plataforma Java.

#13

Não sei, pra mim Groovy vai ser o boi de piranha da plataforma Java, ela deve funcionar muito mais como um “meio” pra que gente que não acredita em linguagens dinâmicas ou que nunca mexeu com metaprogramação dar os primeiros passos.

Mas, invariavelmente, esse mesmo cara que começou a andar com Groovy vai perceber que a linguagem tem diversas fraquezas e pontos aonde outras linguagens que já rodam na JVM e se integram muito bem com código Java se dão bem melhor (como Scala e JRuby) e vai terminar largando Groovy.

De qualquer forma, eu acho que Groovy é uma ótima opção pra quando você não pode (ou não quer) dar uma virada muito brusca, ela ainda dá um falso sentimento de “segurança” pra um programador engessado em Java, gerentes que vieram da época dos escravagistas ou quando você quer adicionar capacidades dinâmicas a uma aplicação Java grande já existente sem fazer um refactoring muito grande no modelo de objetos dela.

#14

Concordo com você, acredito que esta vai ser uma das razões principais para motivar a utilização do GRails.

#15

Com certeza Scala e JRuby são mais interessantes que Groovy. A maior questão para a adoção do Groovy que vejo, nem é tanto por seu legado “quase java”, mas pelo seu desempenho na atualidade, simplificando o desenvolvimento com os diversos frameworks existentes que estão passando a suportá-lo. JRuby ainda precisa de ajustes para rodar razoavelmente bem com Rails em um Application Server da vida. Fora que, sem Rails, pra mim JRuby é como o Ruby, uma linguagem boa mas esquecida pela grande massa, adotada mais por administradores Unix/Linux da vida.

#16

Opa! “Grande” vacilo! :slight_smile:

Qualquer banco de dados embutido eu vejo como uma vantagem. Na realidade, olho para o Grails e para o RoR como ferramentas para trabalhos rápidos e pequenos,que o cliente quer com certa urgência.

Se você já tem um SGBD embutido, é uma preocupação a menos para este tipo de trabalho.

Agora, com relação ao uso destas ferramentas para trabalhos maiores… tenho cá minhas dúvidas.

#17

[quote=Maurício Linhares]O maior problema de Groovy é que ela é próxima demais do Java, então muita coisa não tem como ser feita em Groovy, como mixins, definir novos métodos em tempo de execução (na verdade, até pode se você fizer umas gambis no despacho de métodos, mas é bem mas complicado do que seria em Ruby com um class_eval, module_eval ou ainda um define_method).

Não vi callbacks pra quando uma classe extende a outra (e isso é muito importante pra metaprogramação e seria ainda mais se Groovy tivesse suporte a módulos). Groovy também não tem open classes/modules, deixando você alterar o comportamento de classes já definidas no ambiente (como colocar novos métodos em String). Open classes são uma mão na roda quando voc está mexendo com código alheio que está versionado e você não pode fazer “patches” diretos.

Enfim, o grande problema de Groovy hoje ainda é o suporte fraquinho a metaprogramação e é isso que faz de Ruby uma linguagem bem mais flexível.[/quote]
Maurício, a maior parte das coisas que vc citou Groovy possui. É possivel sim, sem complicação, adicionar novos métodos, propriedades em tempo de execução, mesmo em classes já existentes (como String). Como vc acha que o GORM funciona? É possivel também alterar métodos. Mas é verdade que não há módulos e callbacks no caso de herança.

Algumas coisas que poderia copiar na cara dura de Ruby seria null como object e mixins. O mais próximo que Groovy tem de mixins são marcações, no Grails, para indicar que uma classe deve ser alterada - veja só - em tempo de execução.

valeuz…

#18

Veja que eu disse:

(na verdade, até pode se você fizer umas gambis no despacho de métodos)

Mas é muito mais complicado do que simplesmente fazer um define_method (ou module_eval e class_eval) em Ruby, você tem sempre que fazer override de “invokeMethod()” (a não ser que tenha mudado desde a última vez que eu mexi com isso em Groovy), o que termina sendo quase igual a ter sempre que fazer override de method_missig em Ruby, o que não é interessante, principalmente porque não tem um alias_method em Groovy.

#19

[quote=Maurício Linhares]Veja que eu disse:

(na verdade, até pode se você fizer umas gambis no despacho de métodos)

Mas é muito mais complicado do que simplesmente fazer um define_method (ou module_eval e class_eval) em Ruby, você tem sempre que fazer override de “invokeMethod()” (a não ser que tenha mudado desde a última vez que eu mexi com isso em Groovy), o que termina sendo quase igual a ter sempre que fazer override de method_missig em Ruby, o que não é interessante, principalmente porque não tem um alias_method em Groovy.[/quote]

String.metaClass.reverse = { -> new StringBuilder(delegate).reverse() } 'Mauricio'.reverse()
É assim que funciona hoje em dia. Adicionar propriedades é simples também:

String.metaClass.getTamanho << { -> delegate.length() } 'minha string'.tamanho
valeuz…

#20

Ah, então melhorou demais mesmo :slight_smile:

Onde é que eu acho mais informações sobre isso?

O meu “Groovy In Action” não fala nada dessas mágicas.