Primeiro contato com “var” no Java 10

Em março de 2018 provavelmente (estou cruzando os dedos para não atrasar) vamos ter o lançamento do Java 10 garantindo aquelas evoluções semestrais da plataforma e dos poucos recursos que serão agregados com essa nova versão a inferência do tipo de variável local (JEP 286) é a que mais me interessa.

Ela traz uma nova palavra reservada para a linguagem chamada var e oferece uma opção menos verborragica para declarações de variáveis locais:

var usuarios = new ArrayList<Usuario>();

É você não leu errado não, é uma uma opção menos verborragica para declarações de variáveis locais, então no post de hoje vamos entender melhor onde podemos aplicá-la e quais serão os impactos de sua utilização e será que vamos ter a esperança de um dia termos constantes?


Substituindo declarações por var

Somos pessoas que desenvolvem com Java e naturalmente costumamos digitar o tipo de nossas variáveis duas vezes, uma vez para a declaração e mais uma vez para o inicializa-las:

URL url = new URL("http://openjdk.java.net/");

Nós também temos o costume de declarar variáveis que serão usadas apenas uma vez e muita vezes na próxima linha, como por exemplo:

URL url = new URL("http://openjdk.java.net/");
URLConnection con = url.openConnection();
Reader reader = new BufferedReader(
new InputStreamReader(con.getInputStream())
);

OK! Vamos ser sinceros, nossas mãos não vão cair por escrever esse tanto a mais de código na declaração de uma variável que pode ser facilmente gerada por um atalho de IDE, mas acaba sendo redundante.

A parti do Java 10 podemos escolher se vamos deixar o compilador inferir os tipos usando a palavra reservada var
var url = new URL("http://openjdk.java.net/");
var con = url.openConnection();
var reader = new BufferedReader(
new InputStreamReader(con.getInputStream())
);

Isso se tornou possível porque a parti do Java 10 o compilador da linguagem ao encontrar a palavra var no teu código vai saber que o tipo da variável vai estar no lado direito da declaração.

Para aqueles que não gostaram do novo estilo ou estão preocupados com possíveis impactos, no resultado final (o bytecode gerado) será de um código fortemente tipado, ou seja:

//como eu escrevo
var numeroDez = 10;
var usuario = new Usuario();
var minhaLista = List.of("1","2","3","4","5");
//como fica depois de compilado
int numeroDez = 10;
Usuario usuario = new Usuario();
List<String> minhaLista = List.of("1","2","3","4","5");

Veja na prática com Nicolai Parlog como isso vai funcionar


Mas, e ai, onde usar esse negócio?

A JEP 286 nós informa precisamente que devemos usar somente nas declarações de variáveis locais com inicializadores!

//errado
var nomeDoFilho;
nomeDoFilho = pai.getNomeDoFilho();
//certo
var nomeDoFilho = pai.getNomeDoFilho();

Ah! Também não vamos conseguir usar essa novidade com retorno de métodos ou para armazenar funções lambdas e métodos de referência, o que é uma pena.

//nada disso vai funcionar
var ints = {0, 1, 2};
var appendSpace = a -> a + " ";
var compareString = String::compareTo;
//usar como retorno de metodos também não vai funcionar
class Pai {
...
 public var getNomeDoFilho(){
return this.nomeDoFilho;
}
}

No começo achei que isso era uma limitação técnica do novo recurso, todavia conversando Nicolai Parlog ficou claro que foi uma decisão de design.

Lembrem-se que o Java continua sendo uma linguagem fortemente tipada então sabiamente a galera que trabalha na evolução do JDK tratou de evitar erros de ações á distância (Action at a distance).

Projeto Amber, um caminho mais jovem para o Java

Java é uma linguagem muito verbosa, na época em que seu estilo foi desenhado ser tão detalhada ajudava muito no entendimento (ainda acho que ajuda), mas com a chegada de linguagens mais jovens, o Java passou a ser bastante criticado nesse quesito.

Por isso o projeto Amber visa explorar e incubar recursos de linguagem Java orientados para a produtividade, ele tem objetivo reduzir escrita e leitura de código Java, foi nesse projeto que o recurso var nasceu.

Então teremos constantes locais também?

Por enquanto nada de val ou let por aqui. O motivo é simples, como estamos trabalhando em um contexto de valores locais e queremos manter a imutabilidade de nossos valores podemos continuar utilizando a palavra reservada final ao invés de criar uma nova.

final var usuario = new Usuario("Mateus Malaquias");

A minha conclusão é que…

Ainda não dá pra saber se a novidade vai virar padrão de desenvolvimento ou não, todavia devemos pelo menos tentar já que é notável a redução de código nesse contexto.

Para nós que desenvolvemos com Java esta é uma chance de criarmos códigos menos verbosos e mais legíveis que não geram impactos após compilação, caso queira saber mais sobre acompanhe a galera do projeto Amber.