Já faz exatamente 2 meses desde o lançamento do Java 9. De acordo com o novo cronograma, a próxima versão do Java será lançada em março de 2018. O escopo completo do Java 10 ainda está sendo confirmado. Isso significa que mudanças significativas ainda podem ocorrer no conteúdo da versão entre agora e a data de disponibilidade geral. Entretanto, é possível ter uma ideia razoável do que os desenvolvedores podem esperar com o Java 10.
Novas funcionalidades e melhorias estão mapeadas através de Java Enhancement Process (JEPs), ou através do Java Community Process para requisições de padronização (JSRs). Com o prazo curto e, consequentemente, escopo pequeno, as mudanças no Java 10 chegarão como JEPs e podem ser rastreadas através do respectivo número de JEP.
As funcionalidades mais prováveis para o Java 10 parecem ser aquelas contidas em JEPs já marcadas ou propostas para serem marcadas. A lista atual contempla as seguintes funcionalidades:
- 286: Inferência de Local-Variable Type;
- 296: Consolidar o JDK Forest em um único repositório;
- 304: Garbage-Collector Interface;
- 307: Parallel Full GC para o G1;
- 310: Application Class-Data Sharing;
- 312: Thread-Local Handshakes.
Destas, a JEP 296 trata apenas de ajustes e a JEP 304 aperfeiçoa o isolamento de código de diferentes garbage collectors e introduz uma interface limpa para os garbage collectors.
O último significa que será mais fácil produzir uma versão do JDK que contenha ou exclua algum algoritmo específico do GC. Isso faz sentido com as novas abordagens do GC como Shenandoah, ZGC e Epsilon em desenvolvimento. Existem esforços dentro da comunidade para depreciar e até mesmo remover o coletor Concurrent-Mark-Sweep (CMS), embora não haja substituição viável de qualidade de produção até o momento.
A mudança que provavelmente despertará maior interesse é a JEP 286, que permite ao desenvolvedor reduzir a quantidade de código na declaração de variáveis através da inferência de tipos. Isso significa que o código a seguir será válido na próxima versão:
var list = new ArrayList(); // infere ArrayList var stream = list.stream(); // infere Stream
Essa sintaxe é restrita a variáveis locais com inicializadores e as usadas para loops.
É algo puramente sintático implementado no compilador de código fonte e não tem significado semântico. Mesmo assim, a experiência demonstra que essa funcionalidade provavelmente provocará um debate animado entre os desenvolvedores Java.
Embora potencialmente pequeno, as três mudanças restantes também têm algum impacto no desempenho.
A JEP 307 resolve um problema com o garbage collector G1; a partir do Java 9, a implementação atual do GC completo para G1 usa um único algoritmo (serial).
Isso significa que se o G1 tiver que voltar para realizar um full GC, espera-se um choque de desempenho desagradável. O esforço da JEP 307 é paralelizar o algoritmo do full GC de modo que, no caso improvável de um G1 Full GC, o mesmo número de threads possa ser usado como nas coleções simultâneas.
A JEP 310 estende uma funcionalidade chamada Class-Data Sharing (CDS), permitindo que uma JVM grave um conjunto de classes e processos em um arquivo compartilhado. Assim, este arquivo pode ser mapeado na memória em um processo da JVM para reduzir o tempo de inicialização em uma próxima execução. O arquivo pode ser compartilhado através de JVMs e isso pode reduzir o uso da memória quando várias JVMs estão sendo executadas no mesmo host.
Isso existe desde o Java 5, mas a partir do Java 9, o CDS somente permite que o bootstrap class loader carregue classes arquivadas. O esforço da JEP 310 é estender isso para permitir que a aplicação e classloaders customizados façam uso de arquivos. Essa funcionalidade na verdade já existe, porém atualmente só está disponível no JDK da Oracle e não no OpenJDK.
Esta JEP portanto, consiste essencialmente em mover a funcionalidade para um repositório aberto a partir das fontes privadas do Oracle. A partir do Java 10 em diante, versões regulares estarão nos binários do OpenJDK. A disponibilização desta funcionalidade em repositórios públicos indica que existem clientes Oracle que estão usando essa funcionalidade e logo a Oracle terá que suportá-los em um binário OpenJDK.
Finalmente, a JEP 312 estabelece as bases para melhorar o desempenho da VM, tornando possível a execução de um callback nas threads da aplicação sem ter que executar um ponto de segurança global na VM. Isso significa que a JVM poderia parar threads individualmente ao invés de parar todas. Algumas das melhorias pequenas que permitem isso incluem:
- Redução do impacto de adquirir um exemplo de stack trace;
- Melhor exemplo de stack trace reduzindo a dependência nos sinais;
- Melhorando o bloqueio tendencioso apenas parando threads individuais para revogar tendências;
- Remoção de algumas barreiras de memória da JVM.
No geral, parece que o Java 10 provavelmente não conterá novos recursos ou melhorias importantes de desempenho Isso talvez já seja esperado: ao invés de uma grande mudança, representa o primeiro lançamento no novo ciclo de versões mais frequentes e graduais.