Java 7 terá a cara do Groovy?

O que seria interpolação de Strings?

Concordo que pode ficar parecido, tá até na hora de colocar features que facilitam a vida do programador, e que faça a mesma coisa com menos código (como dar uma aliviada nos Generics e tirar o Erasure), porém acho que a sintaxe de closure do Groovy bem melhor que todas as propostas feitas pra Java.

Bruno Laturner:

O que seria interpolação de Strings?

Concordo que pode ficar parecido, tá até na hora de colocar features que facilitam a vida do programador, e que faça a mesma coisa com menos código (como dar uma aliviada nos Generics e tirar o Erasure), porém acho que a sintaxe de closure do Groovy bem melhor que todas as propostas feitas pra Java.

Interpolação de strings consiste na possibilidade de incluir valores em uma String sem precisar de concatenação.

Algo como

String valor = “Meu nome é ${usuario.nome}”

Tô meio por fora, alguém pode me citar uma vantagem nesse aspecto de String?

Seu código fica mais simples.
Por exemplo, ao invés de escrever algo como

String valor = "Bom dia " + usuario.getNome() + “!”;

Você poderia escrever

String valor = “Bom dia ${usuario.getNome()}”;

No caso do Groovy, você também pode definir as suas String usando aspas triplas, tal como no exemplo abaixo:

String valor = “”" Bom dia Sr. ${usuario.nome}.
É um prazer tê-lo recebido no dia ${encontro.data}.
Volte sempre. A propósito, o que achou do ${produto.nome} que comprou?"""

É muito mais simples de de escrever do que um amontoado de concatenações, tal como fazemos no Java.

As informações sobre o que vai ou não vai estar no J7 são meras opiniões é dificil encontrar o site official com o que vai e não vai entrar.

Algumas coisas são realmente bem prováveis de serem incorporadas. Básicamente quase todas as que tiverem uma JSR associada.
As api de datas, a de super pacotes e do novo bytecode invokedynamic parecem ser seguras, enquanto outras como closures e generics sem erasure ( que melhoraria a refelction) parecem mais difíceis. Algumas parecem impossíveis como suporte sintático a xml. (quem usaria isso ?)

Na realidade a discussão sobre closures não é tanto qual opção é melhor ( é evidente qual é a melhor) e sim se java deve ter closures ou se bastaria suportar closures no nivel do bytecode ( com invoke dynamic e outros truques). Básicamente a ideia é melhorar a plataforma e não tanto a linguagem. Isso deixa caminho para a concurrencia de linguagens começar. JRuby e JPyton parecem certas como adendos para o scripting framework, mas ainda existem poucas linguagens que compilem directamente para bytecode como java. A que mais se aproxima é o groovy que não funciona por meio do scripting framework e sim nativamente como o proprio java ( via classloader injection)

Incluir no java as features do groovy seria , no minimo, absurdo. Java não é construido para ser uma linguagem de script. É linguagem para ser segura , simples e clara. Linguagens de script não são claras nem simples devido ao seus truques de sintaxe.

Algumas featues da JVM tb parecem importantes e seguras , como o novo garbage collector e o novo modo de funcionamento se mistura as jvm cliente e servidor. Ou seja, ainda melhor performance.