Eis uma nova linguagem filha do java!!!
Andei olhando e vi algumas coisas legais nela!!!
Tem um compilador próprio!!!
Acham que é um dos futuros caminhos do java???
nova?! :shock:
[quote=lelodois]Eis uma nova linguagem filha do java!!!
Andei olhando e vi algumas coisas legais nela!!!
Tem um compilador próprio!!!
Acham que é um dos futuros caminhos do java???[/quote]
Não. A linguagem java sempre será a linguagem java.
Agora, a plataforma java está ganhando um monte de linguagens como groovy ou JRuby.
A JRuby por exemplo é mais eficiente que o Ruby original porque a JVM é muito mais eficiente e bem desenhada do que a do Ruby.
Tb acho groovy legal e para DSL é uma mão na roda. Agora, quanto a substituir a linguagem java, nem pensar. Groovy não tem tipos primitivos, por exemplo.
Uma das próxima versões do java (não sei se a 7 ou a 8) terá suporte a métodos como objetos, logo o conceito de closure será muito mais entendido pela JVM melhorando ainda mais a eficiencia.
Eu diria que ainda está para ser criada a linguagem de programação que justifique mais do que um ponto de exclamação. 
Groovy nasceu tortou, chegou a uma versão 1.0 que era muito fraquinha, e foi reescrito praticamente do zero, numa das mais bem-sucedidas recuperações de projeto open source da história. Ele tem um monte de features legais, ainda mais na versão 1.5. Não ter tipos primitivos é um deles.
hehe :lol: para linguagem de script não ter tipos primitivos é otimo. Não sei se é tão bom usar BigDecimal para tudo, mas ok. Eu me referia ao Groovy como subtituição do Java. Java tem primitivos porque em certas circunstâncias eles são necessários. Como o Goovy usa toda a API java ele se benificia do uso de primitivos das API, mas essas API não poderão ser escritas em Groovy. Por isso, ele nunca substituirá o Java.
É algo diferente das várias linguagens .NET que seguem ± os mesmos padrões só mudando a sintaxe. Os ports de scripts para JVM não seguem os mesmos padrões. Exactamente por isso são interessantes, mas tb , exactamente por isso não podem substitui a linguagem Java.
Como linguagem de script é otimo. As ideias são boas. Agora, como implementação e eficiência é outra conversa.
A eficiência tende a aumentar tal como a da JVM a implementação mudará com as novas tecnologias da JVM.
Eu só não usei o groovy ainda por que ainda não consegui pensar numa forma util de o integrar num projeto, mas quem é da moda “on Rails” tlv goste do Grails (Goovy On Rails). Tem o mesmo conceito do Ruby on Rails
mas em java , com a sintaxe java e podendo usar toda a API do java e Application Servers
hehe :lol: para linguagem de script não ter tipos primitivos é otimo. Não sei se é tão bom usar BigDecimal para tudo, mas ok. Eu me referia ao Groovy como subtituição do Java. Java tem primitivos porque em certas circunstâncias eles são necessários. Como o Goovy usa toda a API java ele se benificia do uso de primitivos das API, mas essas API não poderão ser escritas em Groovy. Por isso, ele nunca substituirá o Java.
É algo diferente das várias linguagens .NET que seguem ± os mesmos padrões só mudando a sintaxe. Os ports de scripts para JVM não seguem os mesmos padrões. Exactamente por isso são interessantes, mas tb , exactamente por isso não podem substitui a linguagem Java.
Como linguagem de script é otimo. As ideias são boas. Agora, como implementação e eficiência é outra conversa.
A eficiência tende a aumentar tal como a da JVM a implementação mudará com as novas tecnologias da JVM.
Eu só não usei o groovy ainda por que ainda não consegui pensar numa forma util de o integrar num projeto, mas quem é da moda “on Rails” tlv goste do Grails (Goovy On Rails). Tem o mesmo conceito do Ruby on Rails
mas em java , com a sintaxe java e podendo usar toda a API do java e Application Servers[/quote]
Observe bem que Groovy não é tão somente uma linguagem de scripts. É também a segunda linguagem oficial de Java, o que isso quer dizer? Que segue as características do Java, mas com as vantagens imensas de ser no modelo script. JRuby é provavelmente a terceira linguagem que em breve se tornará oficial do Java.
Grails é bacana, mas não substitui as facilidades de Rails. Eu uso JRuby on Rails e sinceramente, dá conta do recado e, inclusive, acesso toda a API do Java.
[]'s
Estamos usando Groovy desde os primeiros betas (inclusive, abrimos reportamos alguns bugs e reportamos aos desenvolvedores).
É realmente excelente.
Integração de um-para-um com o Java. Também é fácil criar proxies e controlar o funcionamento do script via código.
É interessante também que é possível fazer reflexão nos scripts. O que significa que é fácil você alterar o método de execução padrão para um método seu (ou vários métodos seus).
Realmente, pelos benchmarks que eu vi por aí, a performance do Groovy é ridícula se comparada a Java. Coisa de mais de 70 vezes mais lento em operações comuns como instanciar um objeto. Ainda assim, eu acredito que as linguagens dinâmicas vão ocupar cada vez mais espaço do Java tradicional, principalmente na web. Para criar CRUDs ou uma interface gráfica que se comunique com um back-end via web services, a velocidade de processamento não importa, porque os gargalos são outros. Com o tempo Java vai ser utilizado cada vez mais para aumentar a performance de trechos críticos de código, como C hoje em dia.
E se vc comparar Groovy com JRuby, verá que a diferença também é grande em favor ao Groovy.
Agora, explica isso para um gestor, que seu parque tecnológico terá um aumento de TCO em razão da produtividade.
Em alguns casos , pode ser que a conta compense, por valor hora profissional, tempo - custo de time-to-marketing, entretanto em outros a conta não vai fechar.
[quote=sergiotaborda]Tb acho groovy legal e para DSL é uma mão na roda.[/quote]Domain Specifc Language certo Sérgio?? Faço uma vaga idéia do quê isso seja mas gostaria de alguns links, se possível, pra estudar DSL. Agradeço qq link.
A chamada de métodos do groovy é mais lenta mesmo, pois o groovy tem bindings para que uma chamada de métodos seja alterada em tempo de execução. E isso dá muito poder a linguagem.
Mas cuidado, uma chamada de métodos, por si só, dificilmente gera problemas de performance. O importante é que a execução interna do código não tem praticamente diferença de performance nenhuma. Aqui rodamos scripts em groovy com carga, que gerenciam testes com timeouts na casa de dezenas de milisegundos, e não temos problemas de performance.