Java 7 vai ter a cara do Groovy?

Confesso: sou louco por Groovy! Sendo assim, fico muito feliz ao ver que dentre as novas features previstas para o Java 7, encontram-se itens que me fizeram adorar Groovy. Ao imaginar como será o código gerado na nova versão do Java caso estas features passem, percebe-se nítidamente que será incrivelmente parecido com Groovy. Basta listar alguns novos recursos:

Closures: previsto para o Java 7 (muito provável de não ser mais incluído na especificação). Tal como podemos hoje fazer em Groovy


def minhaClosureDuplica = {x -> x * 2}

, se a JSR passar, poderemos ter o mesmo em Java. E acredite, elas realmente quebram um tronco!

Operadores com BigDecimal: eis algo que acho incrívelmente chato em Java. Em Groovy, operamos com valores do tipo BigDecimal assim como fazemos com tipos primitivos numéricos. Agora, ao que tudo indica, o mesmo poderá ser feito com Java. 

Switch com strings: eis algo que há muito tempo sinto falta em Java. Em groovy, qualquer tipo de objeto pode ser usado como comparação dentro de um switch. Em Java, por enquanto, apenas tipos inteiros ou enums. Ao que tudo indica, isto irá mudar também. Nada mais lógico, visto que no final das contas, o switch nada mais é do que um if encadeado.

Propriedades: há bastante discussão a respeito de incluir ou não propriedades a la Groovy no Java 7. Pessoalmente, achava esta inclusão uma grande bobagem até começar a programar em Groovy, aonde só crio métodos gets e sets se quiser incluir alguma lógica de negócio dentro dos mesmos. Acredite: realmente poupa MUITO tempo e linhas de código (um dos recursos que mais uso no Netbeans consiste no encapsulador de atributos).

Interpolação de strings: assim como em Groovy, vemos este recurso também em Ruby, PHP e diversas outras linguagens. Demorou para aparecer em Java também!

A inclusão de novos recursos na linguagem é interessante, no entanto, surge a dúvida: será realmente uma boa idéia este jogo de “eu também” que vemos ocorrer no Java? Não estaríamos correndo o risco de poluir a linguagem, tornando ainda mais difícil escrever novos compiladores para a mesma?

Meu lado egoista vê com bons olhos estas novas inclusões (tornam Java mais perto de algo no qual adoro trabalhar). Já meu lado pragmático teme que no futuro Java vire um balaio de gato.

4 thoughts on “Java 7 vai ter a cara do Groovy?

  1. Bom, eu ainda não conheço o Groovy. Concordo que o fato de não ser possivel fazer operadores com bigdecimal ou switch com strings é uma coisa que deixa a desejar no Java. No entato, ficar adicionando mais e mais funcionalidades em uma arquitetura não é um trabalho simples e pode acabar apresentando problemas futuros, seja para os compiladores quanto sistemas desenvolvidos. Tive diversas experiencias quanto a versão de VM´s e acho que isso não deveria existir em uma plataforma considerada 100% portável. Também temo o tal “balaio de gato.”

    Responda

  2. São recursos muito bons, mas se você quer usá-los, porque usar Java e não Groovy?

    Responda

    Henrique Lobo Weissmann Reply:

    Penso mais por este lado também. Não sei se a adição de todos estes recursos no Java irá de fato enriquecer a linguagem ou transformá-la em um balaio de gato.

    Pessoalmente, acho que a postura ideal deveria deixar a linguagem Java exatamente como está hoje, e deixar estas features para aqueles que queiram usar outras linguagens dentro da JVM, como Groovy, Scala, Ruby, etc.

    Responda

  3. Concordo parcialmente com o Weissmann. Acho que deveriam melhorar a linguagen e até melhorar a JVM(como incluindo tail call recursion) para permitir que as linguagens dinâmicas e o proprio java tenham melhor performance, mas nao acho que a linguagem java deveria mudar tanto.

    É aquele historia, java como plataforma é excelente e deve ser evoluir sempre mas ninguem mais aguenta a linguagem java(apesar de ter o seu espaço e sua utilidade).

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>