EMAG | JAVA: PRESENTE E FUTURO

05. Onde foi parar o PermGen do Java?

11. 8 funcionalidades pouco conhecidas do Java 8

15. Anotações de tipos no Java 8: Ferramentas

e oportunidades

22. Java 8: Desmistificando Lambdas

29. Quão funcional é o Java 8?

33. Java 7 - Características que viabilizam o Java 8

36. Q&A: Novidades do Java 8

38. Do Groovy ao Java 8

42. Nashorn: Combinando o poder do Java

e JavaScript no JDK 8

49. Java 9 e além: Brian Goetz e John Rose falam

sobre o futuro do Java

51. Novos Horizontes do Java

2 InfoQ Brasil
 CONTEÚDO DETALHADO
Onde foi parar o PermGen do Java? . . . . . . . . . . . . . . . . . . . . . 5 Programação funcional em linguagens não
Adeus PermGen. Olá Metaspace! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Mudança para o Metaspace e suas alocações . . . . . . . . . . . . . . . . 6 Java - um pouco de história . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Otimização e Metaspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 O sistema de tipos original do Java . . . . . . . . . . . . . . . . . . . . . . 30
Questões Atuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Alternativas a tipos nomeados . . . . . . . . . . . . . . . . . . . . . . . . . . 31
O sistema de tipos do Java 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8 funcionalidades pouco conhecidas do Java 8 . . 11 Recursos introduzidos no Java 6 e 7 . . . . . . . . . . . . . . . . . . . . . 31
1. StampedLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 O sistema de tipos do Java 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2. Adicionadores concorrentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Quão funcional é o Java 8? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3. Ordenação Paralela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
4. Migrando para nova API de data . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Java 7: Características que viabilizam o Java 8 . . . 33
5. Controle de processos do sistema operacional . . . . . . . . . . 13 Operador Diamante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. Operações numéricas precisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Manipulador de Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Geração segura de números aleatórios . . . . . . . . . . . . . . . . . . . 13 invokedynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Referências opcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Anotações de tipos no Java 8: Ferramentas Q&A: Novidades do Java 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

e oportunidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Sintaxe das anotações de tipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Do Groovy ao Java 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Detectando erros com anotações . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
O framework Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Nashorn: Combinando o poder do Java
Aumentando a produtividade com anotações de tipo . . . . 19 e JavaScript no JDK 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A estrada à frente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Shell scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Passando dados para o Java e vice-versa . . . . . . . . . . . . . . . . 45
Usando classes Java no Nashorn . . . . . . . . . . . . . . . . . . . . . . . . 45
Java 8: Desmistificando Lambdas . . . . . . . . . . . . . . . . . . . . . . 22 Linguagem funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Referência de métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Dialeto especial do JavaScript no Nashorn . . . . . . . . . . . . . . 46
Evolução da biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Avatar.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Operações de agregação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Resumindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Fontes de stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Operações de finalização de Stream . . . . . . . . . . . . . . . . . . . . . . . . . 26 Java 9 e além: Brian Goetz e John Rose falam
Inteface Iterable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 sobre o futuro do Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Novos Horizontes do Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Quão funcional é o Java 8? . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Primeiros anúncios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
O que é uma linguagem de programação funcional? . . . . 29 Outras novidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Data final quase definida, com alguns sacrifícios . . . . . . . . . 52
 APRESENTAÇÃO

O
Java 8 é o release atual do Java desde 2014, mas para alguns
ainda é um sonho que o legado não deixa se concretizar. Por
outro lado, ambientes empresariais e grupos de desenvolve-
dores estão se modernizando e gradualmente tornando o novo Java
mainstream. Com o Java 9 planejado para o primeiro semestre de
2017, a versão 8 da linguagem/plataforma mais popular do mundo é
a realidade que queremos conhecer e alcançar hoje. Com essa eMag,
buscamos oferecer uma base para você explorar as muitas novidades
do Java 8 – de novas APIs a mudanças na linguagem. Também vis-
lumbramos um pouco do futuro, concluindo essa coleção de artigos
do InfoQ com um apanhado do que está por vir no Java 9.

O Java 8 contém novas funcionalidades, aprimoramentos e corre-

ções de bugs para maior eficiência no desenvolvimento e na execução;
traz features voltadas ao aumento de produtividade e facilidade de
uso, além de melhorias em programação poliglota, segurança e per-
formance. Se as versões 6 e 7 do Java foram alterações consideradas
leves, o Java 8 está em outro patamar. Mais de 56 novas funciona-
lidades foram adicionadas. Chegaram os lambdas, métodos padrão,
interfaces funcionais e a API de streams, modificando radicalmente
a linguagem e portanto todo o ecossistema Java. Há ainda uma nova
API para datas, novas anotações e aumento de desempenho do engi-
ne para JavaScript.

Neste eMag, o InfoQ leva praticantes numa visita através do Java

8 e as futuras versões da linguagem, explorando como chegamos até
aqui e algumas formas que seguiremos adiante com a tecnologia.

4 InfoQ Brasil
ONDE FOI PARAR O PERMGEN DO JAVA?
por Monica Beckwith, traduzido por Rafael Brito
Com a introdução do JDK8, não existe mais o espaço de PermGen. Os metadados que antes eram armazenados no PermGen não desapareceram,
mas foram movidos para a memória nativa, em uma área conhecida como “Metaspace”. Conheça neste artigo maiores detalhes desta importante
mudança da plataforma Java.

A
Máquina Virtual do Java
(JVM) utiliza uma represen-
tação interna de suas classes
contendo uma série de metadados por
classe, tais como: informações de hie-
rarquia de classes, dados e informa-
ções de métodos (tais como byteco-
des, pilha e tamanho de variáveis), o
pool contínuo em tempo de execução,
resoluções de referências simbólicas e
Vtables.
Anteriormente, quando os class-
loaders customizados não eram tão
comuns, as classes eram “estáticas”
em sua maioria, raramente eram des-
carregadas ou coletadas, e consequen-
temente eram marcadas como “per-
manentes”. Além disso, desde que as
classes fizessem parte da implemen-
tação da JVM, e não fossem criadas
pela aplicação, elas eram considera-
das como “memória não pertencente
ao heap”.
Na JVM HotSpot antecessora ao
JDK8, a representação “permanente”
ficava em uma área chamada per-
manent generation (“geração perma-
nente”). A geração permanente era
contígua ao heap do Java e limitada a
-XX:MaxPermSize, que precisava ser
configurada por linha de comando
antes de iniciar a JVM, caso contrá-
rio seria iniciada com o valor padrão
de 64M (85M para 64bit scaled poin-
ters - ponteiros auto-incrementáveis
com deslocamentos constantes, que
facilitam o acesso à estrutura). A co-
leção da geração permanente ficaria
associada à coleção da antiga gera-
ção, então sempre que alguma delas
ficassem cheias, ambas as gerações
(permanentes e antigas) seriam cole-
tadas. Um dos problemas mais óbvios
que se pode verificar de imediato é a
dependência do -XX:MaxPermSize. Se
o tamanho das classes de metadados
estiver além dos limites do -XX:Max-
PermSize, sua aplicação será execu-
tada com pouco espaço de memória
e um erro de “Out of Memory” será
apresentado.
Curiosidade: Antes do JDK7, para
a JVM HotSpot, as Strings internali-
zadas (interned) também eram manti-
das na geração permanente, também
conhecida como PermGen, causan-
do muitos problemas e erros de Out
of Memory. Para mais informações
acesse a documentação desse proble-
ma.

eMag | Java: Presente e Futuro 5

Adeus PermGen.
Olá Metaspace!
Com o surgimento do JDK8, Perm-
Gen não existe mais. As informações
de metadados não desapareceram, só
que o espaço em que eram mantidos
não é mais contíguo ao heap. Agora, o
metadado foi movido para a memória
nativa, em uma área conhecida como
“Metaspace”.
Mudança para o Metaspace e
suas alocações
Agora a VM Metaspace (Máquina
Virtual Metaspace) emprega técnicas
de gerenciamento de memória para
gerenciar o Metaspace. Movendo as-
sim o trabalho de diferentes coletores
de lixo para uma única VM Metas-
pace. Uma questão por trás do Me-
taspace reside no fato de que o ciclo
de vida das classes e seus metadados
corresponde ao ciclo de vida dos clas-
sloaders. Isto é, quanto mais tempo o
classloader estiver ativo, mais o meta-
dado permanecerá ativo no Metaspa-
ce e não poderá ser liberado.
Temos usado o termo “Metaspace”
de forma muito vaga neste texto. Mais
6 InfoQ Brasil
A mudança para o Metaspace foi
necessária, pois era realmente difícil
de se fazer o ajuste fino (tunning) do
PermGen. Havia ainda a possibilida-
de dos metadados serem ser movidos
por qualquer coleta de lixo completa.
Além disso, era difícil dimensionar
o PermGen, uma vez que o seu ta-
manho dependia de muitos fatores,
tais como: o número total de classes,
tamanho dos pools constantes, tama-
formalmente, a área de armazenagem
por classloader é chamado de “me-
taspace”, e estes metaspaces são co-
letivamente chamados “Metaspace”.
A reciclagem ou recuperação de me-
taspace por classloader pode ocorrer
somente depois que o seu classloader
não estiver mais ativo e foi relatado
como inativo pelo coletor de lixo. Não
há realocação ou compactação nestes
metaspaces, mas os metadados são
varridos por referências Java.
A VM Metaspace gerencia a alo-
cação de Metaspace empregando um
alocador de segmentos. O tamanho
dos segmentos depende do tipo de
classloader. Há uma lista global de
segmentos livres. Sempre que um
nhos dos métodos etc.
Adicionalmente, cada garbage col-
lector na HotSpot precisava de um có-
digo especializado para lidar com os
metadados no PermGen. Desacoplar
os metadados do PermGen não só
permite o gerenciamento contínuo do
Metaspace, como também melhorias,
tais como: simplificação da coleta de
lixo completa e futura desalocação
concorrente de metadados de classe.
classloader precisa de um segmento,
remove-o da lista global e mantém a
sua própria lista de segmentos. Quan-
do algum classloader é finalizado,
seus segmentos são liberados e retor-
nam novamente para a lista global de
segmentos livres. Esses segmentos
são posteriormente divididos em blo-
cos e cada bloco contém uma unidade
de metadados. A alocação de blocos
dos segmentos é linear (ponteiro de
colisão). Os segmentos são alocados
fora dos espaços de memória mape-
ada (mmapped). Há uma lista ligada
para os tais espaços globais mmapped
virtuais, e sempre que algum espaço
virtual é esvaziado, ele é devolvido ao
sistema operacional.
 A figura acima mostra a alocação
de Metaspace com metasegmentos
em um espaço virtual mmapped. Os
Classloaders 1 e 3 representam a re-
flexão ou classloaders anônimos e
empregam segmentos de tamanhos
“específicos”. Os Classloaders 2 e 4
podem ser empregados em segmen-
tos de tamanho pequeno ou médio,
baseado no número de itens em seus
carregadores.
Otimização e Metaspace
Como mencionado anteriormen-
te, uma VM Metaspace gerenciará
o crescimento do Metaspace, mas
talvez surgirão cenários em que se
deseje limitar o crescimento através
do uso da configuração explícita do
-XX:MaxMetaspaceSize via linha de
comando. Por padrão, o -XX:MaxMe-
taspaceSize não possui um limite,
então, tecnicamente, o tamanho do
Metaspace poderia assumir o espaço
de swap, e começaria a gerar falhas de
alocação nativa.
Para uma JVM servidora de 64 bits,
o valor padrão/inicial do -XX:Metas-
paceSize é de 21MB. Esta é a configu-
ração do limite máximo inicial. Uma
que vez que esta marca é alcançada,
uma varredura de lixo completa é
disparada para descarregar classes
(quando os seus classloaders não esti-
verem mais ativos), e o limite máximo
é reiniciado. O novo valor deste limite
depende da quantidade de Metaspace
liberado. Se o espaço liberado não for
suficiente, o limite aumenta; se for li-
berado espaço demais, o limite dimi-
nui. Isto será repetido diversas vezes
se o limite inicial for muito baixo, e
será possível constatar a repetida co-
leta de lixo completa nos logs de co-
leta de lixo. Em tal cenário, recebe-se
o aviso para configurar o -XX:Metas-
paceSize para um valor mais elevado
através da linha de comando, para
evitar as coletas de lixo iniciais.
Após coletas subsequentes, a VM
Metaspace será automaticamente
ajustada para o limite mais alto, de
modo a postergar a coleta de lixo do
Metaspace.
Há também duas opções: -XX:Min-
MetaspaceFreeRatio e -XX:MaxMetas-
paceFreeRatio, que são análogas aos
parâmetros do GC FreeRatio e podem
ser configurados através da linha de
comando.
Algumas ferramentas foram mo-
dificadas para ajudar a obter mais
informações sobre o Metaspace, e são
listadas a seguir:
eMag | Java: Presente e Futuro 7
• jmap -clstats <PID>: exibe as estatísticas de um classloader. (Isto agora assume o lugar do -permstat, que era usado
para exibir estatísticas do classloader de JVMs anteriores ao JDK8). Segue um exemplo de saída no momento de
execução do benchmark da DaCapo Avrora:

$ jmap -clstats <PID>

Attaching to process ID 6476, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.5-b02
finding class loader instances ..done.
computing per loader stat ..done.
please wait.. computing liveness.liveness analysis may be inaccurate ...
class_loader classes bytes parent_loader alive? type

<bootstrap> 655 1222734 null live <internal>

0x000000074004a6c0 0 0 0x000000074004a708 dead java/util/ResourceBundle$RBClassLoader@0x00000007c0053e20
0x000000074004a760 0 0 null dead sun/misc/Launcher$ExtClassLoader@0x00000007c002d248
0x00000007401189c8 1 1471 0x00000007400752f8 dead sun/reflect/DelegatingClassLoader@0x00000007c0009870
0x000000074004a708 116 316053 0x000000074004a760 dead sun/misc/Launcher$AppClassLoader@0x00000007c0038190
0x00000007400752f8 538 773854 0x000000074004a708 dead org/dacapo/harness/DacapoClassLoader@0x00000007c00638b0
total = 6 1310 2314112 N/A alive=1, dead=5 N/A

• jstat -gc <LVMID>: agora exibe informações do Metaspace, como demonstra o exemplo a seguir:

$jstat-gc <LVMID>
SOC SIC SOU S1U EC EU OC OU MC UM CCSC CCSU YGC YGCT FGC FGCT GCT
1024.0 1024.0 0.0 96.0 6144.0 2456.3 129536.0 2228.3 7296.0 6550.3 896.0 787.0 229 0.211 33 0.347 0.558

Where, MC: Current Metaspace Capacity (KB); UM: Metaspace Utilization (KB)

• jcmd <PID> GC.class_stats: Este é um novo comando de diagnóstico que permite ao usuário final se conectar à
JVM em execução, e obter um histograma detalhado dos metadados das classes Java.

Nota: Com o JDK8 build 13, você deve iniciar o Java com -XX:+UnlockDiagnosticVMOptions.

$ jcmd <PID> help GC.class_stats

9522:
GC.class_stats
Provide statistics about Java class meta data. Requires -XX:+UnlockDiagnosticVMOptions.

Impact: High: Depends on Java heap size and content.

Syntax : GC.class_stats [options] [<columns>]

Arguments:
columns : [optional] Comma-separated list of all the columns to show. If not specified, the following columns are shown:
InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes,MethodAll,ROAll,RWAll,Total (STRING, no default value)

Options: (options must be specified using the <key> or <key>=<value> syntax)

-all : [optional] Show all columns (BOOLEAN, false)
-csv : [optional] Print in CSV (comma-separated values) format for spreadsheets (BOOLEAN, false)
-help : [optional] Show meaning of all the columns (BOOLEAN, false)

8 InfoQ Brasil
Um exemplo de saída:

$ jcmd <PID> GC.class_stats

7140:
Index Super InstBytes KlassBytes annotations CpAll MethodCount Bytecodes MethodAll ROAll RWAll Total ClassName
1 -1 426416 480 0 0 0 0 0 24 576 600 [C
2 -1 290136 480 0 0 0 0 0 40 576 616 [Lavro-
ra.arch.legacy.LegacyInstr;
3 -1 269840 480 0 0 0 0 0 24 576 600 [B
4 43 137856 648 0 19248 129 4886 25288 16368 30568 46936 java.lang.Class
5 43 136968 624 0 8760 94 4570 33616 12072 32000 44072 java.lang.String
6 43 75872 560 0 1296 7 149 1400 880 2680 3560 java.
util.HashMap$Node
7 836 57408 608 0 720 3 69 1480 528 2488 3016 avrora.sim.util.
MulticastFSMProbe
8 43 55488 504 0 680 1 31 440 280 1536 1816 avrora.
sim.FiniteStateMachine$State
9 -1 53712 480 0 0 0 0 0 24 576 600 [Ljava.
lang.Object;
10 -1 49424 480 0 0 0 0 0 24 576 600 [I
11 -1 49248 480 0 0 0 0 0 24 576 600 [Lavrora.sim.pla-
tform.ExternalFlash$Page;
12 -1 24400 480 0 0 0 0 0 32 576 608 [Ljava.util.HashMa-
p$Node;
13 394 21408 520 0 600 3 33 1216 432 2080 2512 avrora.sim.AtmelIn-
terpreter$IORegBehavior
14 727 19800 672 0 968 4 71 1240 664 2472 3136 avrora.arch.legacy.
LegacyInstr$MOVW
…<snipped>
…<snipped>
1299 1300 0 608 0 256 1 5 152 104 1024 1128 sun.util.resources.
LocaleNamesBundle
1300 1098 0 608 0 1744 10 290 1808 1176 3208 4384 sun.util.resources.
OpenListResourceBundle
1301 1098 0 616 0 2184 12 395 2200 1480 3800 5280 sun.util.resources.
ParallelListResourceBundle
2244312 794288 2024 2260976 12801 561882 3135144 1906688 4684704 6591392 Total
34.0% 12.1% 0.0% 34.3% - 8.5% 47.6% 28.9% 71.1% 100.0%
Index Super InstBytes KlassBytes annotations CpAll MethodCount Bytecodes MethodAll ROAll RWAll Total ClassName

Questões Atuais
Como mencionado anteriormente, a VM Metaspace emprega um alocador de segmentos. Há múltiplos tamanhos de
segmentos, dependendo do tipo de classloader. Além disso, os itens de classe por si mesmos não possuem um tamanho
fixo, por isso há chances de que os segmentos livres não sejam do mesmo tamanho que os segmentos necessários para os
itens de classe. Tudo isso pode gerar uma fragmentação. A VM Metaspace (ainda) não utiliza compactação, consequente-
mente a fragmentação é uma das principais preocupações neste momento.

eMag | Java: Presente e Futuro 9

 Sobre a Autora
Acompanhe Monica no Twitter:
@mon_beck.

Monica Beckwith é uma engenheira de desempenho

trabalhando na indústria de hardware por mais de uma
década. Seu mais atual título é Arquiteta de Desempenho
na Servergy - uma startup que oferece uma nova classe de
servidores Cleantech hiper-eficientes ®. Antes da Servergy,
Monica trabalhou na Oracle / Sun e AMD otimizando a JVM
para sistemas de classe de servidor. Monica foi eleita uma
palestrante “estrela do rock” no JavaOne 2013.

10 InfoQ Brasil
8 FUNCIONALIDADES POUCO
CONHECIDAS DO JAVA 8
por Tal Weiss, traduzido por Vitor Puente
Este artigo visa apresentar algumas das novas APIs do Java 8 que não estão sendo tão comentadas, mas que tornaram o Java melhor de várias
maneiras.
1. StampedLock
O código multithreaded tem sido um desafio para os
desenvolvedores. Com o tempo, algumas construções
complexas foram adicionadas às bibliotecas Java visando
auxiliar o desenvolvedor com códigos multithreaded, e
seu acesso a recursos compartilhados. Um exemplo é o
ReadWriteLock, que permite ao desenvolvedor dividir o
código em seções que precisam ser mutuamente exclusi-
vas (“writers”) e seções que não precisam (“readers”).
Na teoria parece ótimo. Porém um problema com Re-
adWriteLock é que a aplicação pode ficar muito lenta, às
vezes até dez vezes mais lenta. O Java 8 introduziu um
novo bloqueio ReadWrite, chamado StampedLock. A boa
notícia é que o StampedLock é muito rápido. A má notícia
é que é mais complicado de usar e envolve mais estados. O
StampedLock não é “reentrante”, o que significa que uma
thread pode causar um deadlock envolvendo ela mesma.
O StampedLock possui o modo “otimista”, que emite
uma marcação (stamp) retornada por cada operação de
bloqueio (lock). Essa marcação é utilizada como uma es-
pécie de ingresso. Cada operação de desbloqueio (unlo-
ck) precisa gerar sua marcação correspondente. Qualquer
thread que adquirir o bloqueio de escrita, enquanto outra
thread está com o bloqueio de escrita do modo otimista,
fará com que o unlock seja invalidado (o stamp não será
mais válido). Nesse ponto, a aplicação pode começar tudo
novamente, possivelmente com um lock no modo “pessi-
mista”, que também é implementado pelo StampedLock.
O gerenciamento de tudo isso fica por conta do desenvol-
vedor. E como um stamp não pode ser utilizado para des-
bloquear outro, deve-se tomar cuidado.
Veja a seguir um exemplo deste tipo de lock em ação:
eMag | Java: Presente e Futuro 11
 long stamp = lock.tryOptimisticRead(); //sem caminho bloqueante - muito rápido.
work (); // é esperado que não ocorra nenhuma escrita por hora.
if (lock.validate(stamp)){
//sucesso! Sem contenção com a thread de escrita.
} else {
//outra thread precisa obter um bloqueio de escrita entretanto mudando o stamp.
//voltando a ter um bloqueio de leitura mais pesado.
stamp = lock.readLock(); //Este é uma operação de leitura que causa o lock.
try {
//Sem escrita acontecendo agora.
work();
} finally {
lock.unlock(stamp); // Liberação do stamp utilizado.
}
}
2. Adicionadores concorrentes
Outra novidade do Java 8 lida especificamente
com código escalável: os “Adicionadores Concorren-
tes (Concurrent Adders)”. Um dos padrões mais bási-
cos de concorrência é a leitura e escrita de contadores
numéricos. Há diversas maneiras de fazer isso hoje
em dia, mas nenhuma tão eficiente ou elegante como
a existente no Java 8.
Antes do Java 8, isso era feito utilizando “Atomics”,
que utilizavam instruções diretas da CPU de compa-
ração e swap (CAS), através da classe sun.misc.Un-
safe, para realizar a tentativa e marcar o valor de um
contador. O problema era que quando um CAS falha-
va devido a uma contenção, o AtomicInteger ficava
em loop, tentando continuamente o CAS em um loop
infinito, até o seu sucesso. Em altos níveis de conten-
ção isso poderia se mostrar muito lento.
A partir do Java 8 foi adicionado o LongAdders.
Esse conjunto de classes fornece uma maneira con-
veniente de leitura e escrita de valores numéricos
em cenários de grande escalabilidade. A utilização é
simples. Basta iniciar um novo LongAdder e utilizar
os seus métodos add() e intValue() para aumentar e
retornar o contador.
A diferença entre esta versão do Atomics e a an-
tiga é que, quando o CAS falha devido a alguma
contenção, em vez de fazer o giro na CPU, o Adder
armazenará o delta em uma célula interna alocada
para aquela thread. Então adicionará o valor junto de
qualquer outro valor de células pendentes ao resul-
tado do método intValue(). Isso reduz a necessidade
de voltar e realizar o CAS novamente, ou bloquear
outras threads.
A utilização do modelo de Adicionadores concor-
rentes deve ser sempre preferido frente ao modelo
Atômico para o gerenciamento de contadores.
12 InfoQ Brasil
3. Ordenação Paralela
Assim como os Adicionadores aceleram os conta-
dores, o Java 8 traz uma maneira concisa de acelerar a
ordenação. E de uma maneira muito simples, em vez
de realizar a ordenação desta maneira:
Array.sort(myArray);
Agora pode utilizar o método pronto para a para-
lelização:
Arrays.parallelSort(myArray);
Isso automaticamente dividirá a sua coleção em
partes, as quais serão ordenadas através de um nú-
mero de “cores” e então agrupadas novamente. Há
uma ressalva, quando o método de ordenação para-
lela é chamado em ambientes com multi-thread ele-
vado, tal como um web container sobrecarregado, os
benefícios iniciais são reduzidos, até mais de 90%, de-
vido ao aumento de trocas de contexto da CPU.
4. Migrando para nova API de data
O Java 8 introduz uma nova API de datas. Uma
nova maneira de lidar com horas e a maioria dos mé-
todos da versão atual estão marcados como obsoletos.
A nova API traz a facilidade de uso e a precisão for-
necidas pela popular API Joda Time para o núcleo da
biblioteca Java.
Assim como em qualquer nova API, as boas novas
são o estilo mais elegante e funcional. Infelizmente,
muito já foi feito com a antiga API e a transição deve-
rá levar tempo.
Para ajudar na transição, a classe Date possui um
novo método chamado “toInstant()”, que converte
uma data para a nova representação. Isso é especial-
mente útil ao fazer uso de APIs que recebe o formato
clássico de data, pois basta converter a data para o
novo formato e utilizar todos os benefícios da nova
API de datas.
5. Controle de processos do sistema
operacional
Lançar um processo do sistema operacional di-
retamente do código Java já é possível através das
chamadas Java Native Interface (JNI), mas com isso é
bem provável se deparar com resultados inesperados
ou exceções sérias mais para a frente. Ainda assim, é
um mal necessário.
Além disso, os processos têm mais um lado desa-
gradável – o fato de tenderem a ficar suspensos. O
problema ao iniciar um processo a partir do código
Java até a versão 7 tem sido difícil o controle sobre um
processo uma vez iniciado.
Para ajudar nessa tarefa o Java 8 traz três novos
métodos na classe “Process”:
1. destroyForcibly() termina um processo com
um grau de sucesso bem maior do que antes;
2. isAlive() informa se um processo iniciado ainda
está vivo;
3. Uma nova sobrecarga de waitFor() especifica a
quantidade de tempo para que o processo termine.
Isso retorna ou o sucesso da execução ou o time-out,
neste último caso é possível terminar o processo.
Duas boas utilizações para estes métodos são:
• Caso um processo não termine no tempo deter-
minado, forçar seu término e seguir em diante:
if (process.wait(MY_TIMEOUT, TimeUnit.MILLISECONDS)){
//success!
} else {
process.destroyForcibly();
} que dependem de um hardware, sistema operacional
• Garantir que, antes que um código termine, não
seja deixado nenhum processo para trás. Proces-
sos suspensos certamente esgotarão seu sistema
operacional, mesmo que lentamente.
for (Process p : processes) {
if (p.isAlive()) {
p.destroyForcibly();
} em que será executado, deve-se considerar o uso des-
} te método. (É uma situação comum quando se cons-
6. Operações numéricas precisas
Um overflow numérico pode causar alguns dos
mais estranhos problemas em software, dada sua
característica implícita. Isso é especialmente verda-
de em sistemas que possuem contadores inteiros in-
crementados de acordo com o tempo. Nesses casos,
recursos que funcionam corretamente em pré-produ-
ção, podem começar a se comportarem de maneira
completamente estranha de repente, quando as ope-
rações sofrem o overflow e produzem valores ines-
perados.
Para auxiliar nesse problema, o Java 8 adicionou
diversos métodos “exact” à classe Math, protegendo
um código suscetível a overflows, através do lança-
mento de “uncheckedArithmeticException” quando
o valor de uma operação causa um overflow.
int safeC = Math.multiplyExact(bigA, bigB);
// Será lançada uma ArithmeticException caso o
resultado exceda +-2^31
O único aspecto negativo disso é que a responsa-
bilidade em identificar como o código pode ter pro-
blemas com overflow fica por conta de quem está de-
senvolvendo. Não há solução mágica, porém isso já é
melhor que nada.
7. Geração segura de números aleatórios
O Java tem sido criticado por anos pelos proble-
mas de segurança. Justo ou não, um grande esforço
tem sido feito para blindar a JVM e os frameworks de
possíveis ataques. Os números aleatórios com baixo
nível de entropia tornam sistemas que os utilizem na
criação de chaves para criptografia ou códigos hash
mais suscetíveis a ataques.
Até o momento, a escolha do algoritmo de geração
de números aleatórios é de responsabilidade do de-
senvolvedor. O problema é que, nas implementações
ou JVM específicos, o algoritmo desejado pode não
estar disponível. Em tais casos, as aplicações têm ten-
dência a migrar para versões mais fracas de gerado-
res, o que aumenta o risco de ataques.
O Java 8 adicionou o novo método SecureRandom.
getInstancStrong() com o objetivo de permitir que a
JVM escolha uma versão segura. Se escrever código
sem o completo controle sobre o hardware/SO/JVM
troem aplicações a serem executadas na nuvem ou
em ambientes de PaaS.)
8. Referências opcionais
As exceções do tipo NullPointerException são bem
antigas. Porém ainda hoje estão presentes no dia-a-
-dia de uma equipe de desenvolvimento, não importa
quão experiente a equipe seja. Para ajudar com este
eMag | Java: Presente e Futuro 13
 problema o Java 8 introduz um novo template cha-
mado Optional<T>.
Baseado em linguagens como Scala e Haskell, esse
template indica explicitamente quando uma referên-
cia passada ou retornada por uma função pode ser
nula. Isso ajuda a reduzir as dúvidas se uma referên-
cia pode ou não ser nula, devido à confiança em do-
cumentações que podem estar desatualizadas, ou a
códigos que podem mudam com o tempo.
Optional<User> tryFindUser(int userID) {
ou
void processUser(User user, Optional<Cart>
shoppingCart) {
O template Optional possui funções que tornam
o trabalho mais conveniente, como “isPresent()” que
verifica se um valor não-nulo está disponível, ou
“ifPresent()”, que recebe uma função Lambda que
será executada caso “isPresent()” seja verdadeiro. O
lado negativo é, assim como ocorre com a nova API
de Data e Hora, levará tempo até que está novidade
esteja presente nas diversas APIs usadas diariamente.
Aqui está a nova sintaxe Lambda para escrever um
valor opcional:
value.ifPresent(System.out::print);

Sobre o Autor

Tal Weiss é o CEO da Takipi. Weiss vem desenhando aplicações escalá-

veis, de tempo real em Java e C++ nos últimos 15 anos. Ele ainda gosta de
analisar um bom bug através da instrumentação de código Java. Em seu
tempo livre Weiss toca Jazz na bateria.

14 InfoQ Brasil
 ANOTAÇÕES DE TIPOS NO JAVA 8: FERRAMENTAS
Epor Todd
OPORTUNIDADES
Schiller, traduzido por Wellington Pinheiro
As anotações no Java 8 podem ser escritas não apenas em declarações, mas também em qualquer uso de tipos como nas declarações, generics e
conversões de tipos (cast). Nesse artigo são apresentadas as anotações de tipos e as ferramentas que ajudam a construir aplicações melhores.
N
as versões anteriores do Java era possível anotar
somente declarações. Com o Java 8 as anotações
podem ser escritas em qualquer local que os ti-
pos são usados, como por exemplo: declarações, generics
e conversões de tipos (casts), como apresentado no código
a seguir:
@Encrypted String data;
List<@NonNull String> strings;
myGraph = (@Immutable Graph) tmpGraph;
À primeira vista, as anotações de tipo não aparentam
ser uma das funcionalidades mais atraentes dessa nova
versão do Java. Ao contrário, em relação à linguagem em
si, as anotações possuem somente uma sintaxe e as fer-
ramentas é que dão a sua semântica, isto é, significado e
comportamento.
Como desenvolvedor Java, é provável que as anotações
já estejam sendo utilizadas para melhorar a qualidade do
software. Considere a anotação @Override, introduzida
no Java 1.5. Em projetos com muitas heranças não triviais,
torna-se difícil rastrear qual implementação de um méto-
do será executado. Nesse contexto, se não forem tomados
os devidos cuidados ao modificar a assinatura de um mé-
todo, isso pode fazer com que o método de uma subclasse
deixe de ser executado, pois ele deixará de sobrescrever
o método da superclasse recém alterado. Eliminar a cha-
mada de um método dessa forma pode introduzir uma
falha ou alguma vulnerabilidade. Em decorrência disso,
a anotação @Override foi introduzida. Ela permite que
os desenvolvedores deixem explícito os métodos que so-
brescrevem outros métodos da superclasse. O compilador
Java usa essa informação para advertir o desenvolvedor
quando o código não reflete essa intenção. Usando essa
abordagem, as anotações agem como um mecanismo
para auxiliar na verificação automática do programa.
Além da verificação automática, as anotações têm de-
sempenhado um papel central para aumentar a produti-
vidade através de técnicas de metaprogramação. A ideia
é que as anotações podem informar as ferramentas sobre
eMag | Java: Presente e Futuro 15
 como gerar código auxiliar, fazer transformações no
código ou definir como o programa deverá se com-
portar em tempo de execução. Por exemplo a API de
persistência JPA (Java Persistence API), introduzida
no Java 1.5, permite que os desenvolvedores especifi-
quem de forma declarativa uma correspondência en-
tre objetos Java e entidades do banco de dados através
de anotações, tal como: @Entity. Ferramentas como o
Hibernate podem usar essas anotações para fazer ma-
peamentos e consultas SQL em tempo de execução.
No caso do JPA e do Hibernate, as anotações são
usadas para evitar a escrita de código repetitivo, re-
duzindo assim a duplicidade de código - princípio co-
nhecido como Não Se Repita (Don’t Repeat Yourself
- DRY). Curiosamente, sempre que se olha para as fer-
ramentas que auxiliam na aplicação de boas práticas,
não é difícil encontrar o uso de anotações. Alguns
exemplos notáveis ajudam na redução do acoplamen-
to através da Injeção de Dependência e também na
separação de responsabilidades com a Programação
Orientada a Aspectos
Mas se as anotações já estão sendo usadas para
melhorar a qualidade do código, por que usar anota-
ções de tipos?
Uma resposta simples é que as anotações de ti-
pos trazem mais possibilidades. Elas permitem, por
exemplo, que mais tipos de falhas sejam detectados
automaticamente e dão mais controle às ferramentas
de produtividade.
Sintaxe das anotações de tipo
As anotações de tipo no Java 8 podem ser escritas
em qualquer local em que um tipo é usado, como por
exemplo:
@Encrypted String data
List<@NonNull String> strings
MyGraph = (@Immutable Graph) tmpGraph;
Criar uma anotação de tipo é muito simples,
basta usar o ElementType.TYPE_PARAMETER,
ElementType.TYPE_USE ou ambos, na definição do
alvo (target) da anotação.
@Target({ElementType.TYPE_PARAMETER, ElementType.TYPE_USE})
public @interface Encrypted { }
O ElementType.TYPE_PARAMETER indica que
a anotação pode ser usada na declaração de tipos, tais
como: classes ou métodos com generics ou ainda jun-
to de caracteres coringa em declarações de tipos anô-
nimos. O ElementType.TYPE_USE indica que a ano-
16 InfoQ Brasil
tação pode ser aplicada em qualquer ponto que um
tipo é usado, por exemplo em declarações, generics e
conversões de tipos (casts). O código a seguir exem-
plifica alguns dos usos desses tipos de anotações:
@TypeUse class MyClass<@TypeParameter T extends @TypeUse
Integer> {
@TypeUse <@TypeParameter S> MyClass(String s) {
...
}
public static void main(String ... args) {
Object o = ( @TypeUse String ) new String( “Test” );
if( o instanceof @TypeUse String ){
...
}
}
}
Assim como as anotações em declarações, as
anotações de tipos podem ser salvas junto com
o arquivo de bytecode gerado e acessadas em
tempo de execução via reflection através das
políticas de retenção: RetentionPolicy.CLASS ou
RetentionPolicy.RUNTIME, usadas na definição
da anotação. Existem duas diferenças fundamentais
entre as anotações de tipo e as suas predecessoras.
Primeiro, as anotações de tipo aplicadas a variáveis
locais podem ser salvas junto com o bytecode.
Segundo, o tipo usado com generics também é salvo
e fica acessível em tempo de execução.
Embora as anotações fiquem disponíveis em tem-
po de execução, elas não afetam a execução do pro-
grama. Por exemplo, um desenvolvedor pode de-
clarar duas variáveis do tipo File e uma variável do
tipo Connection no corpo de um método, da seguinte
forma:
File file = new File(“aFile”);
@Encrypted File encryptedFile = new File(“anEncryptedFile”);
@Open Connection connection = getConnection();
Supondo que a classe Connection tenha um mé-
todo send(File), é possível executar esse método pas-
sando como parâmetro qualquer uma das duas vari-
áveis do tipo File:
connection.send(file);
connection.send(encryptedFile);
Como era de se esperar, a ausência de efeito em
tempo de execução implica que, embora os tipos pos-
sam ser anotados, os métodos não podem ser sobre-
carregados com base nas anotações dos tipos.
public class Connection{
 void send(@Encrypted File file) { ... }
// A tentativa de sobrecarga a seguir resulta em um erro
de compilação
// void send( File file) { ... }
. . .
} outra para o processamento de anotações, de forma
A intuição por trás dessa limitação é que o com-
pilador não tem conhecimento sobre a relação entre
tipos anotados e não anotados ou entre tipos com di-
ferentes anotações.
Repare que há uma anotação @Encrypted na va-
riável encryptedFile coincidindo com o parâmetro
file na assinatura do método send, mas perceba que
não há nada nesse método que corresponda à anota-
ção @Open na variável connection. Quando é feita a
chamada connection.send(...), a variável connection é
conhecida como uma receptora (receiver) do método
(o termo receiver é uma analogia clássica à troca de
mensagens entre objetos na teoria de Orientação a
Objetos). O Java 8 introduz uma nova sintaxe para as
declarações de métodos de forma que anotações de
tipos possam ser escritas em um receptor no método.
void send(@Open Connection this, @Encrypted File file)
Observe nesse último exemplo a sintaxe para defi-
nir o método send. O primeiro parâmetro na verdade
faz referência á instância receptora, por isso o nome
desse parâmetro é “this”.
Como citado anteriormente, as anotações não afe-
tam a execução do programa. Assim, um método
declarado com a nova sintaxe do parâmetro receptor
tem o mesmo comportamento àquele utilizando a
sintaxe tradicional. Na prática, o uso da nova sintaxe
só permite que anotações de tipos sejam escritas no
tipo do receptor.
Uma explicação completa da sintaxe de anotações
de tipos, incluindo sintaxe para arrays multi-dimen-
sionais, pode ser encontrada na especificação JSR
(Java Specification Request) 308.
Detectando erros com anotações
Escrever anotações no código serve para enfatizar
erros quando o código tem algum problema:
@Closed Connection connection = ...;
File file = ...;
… podem ser um superconjunto de valores que sabida-
connection.send(file); // Problema!: fechada e não
criptografada!
Contudo, esse último código de exemplo pode ser
compilado, executado e causará erro durante a execu-
ção. O compilador Java não faz verificações de anota-
ções definidas pelo usuário. Apesar disso, a platafor-
ma Java expõe duas APIs que auxiliam nessa tarefa,
uma para a criação de plugins para o Compilador e
que terceiros possam construir seus próprios méto-
dos de análise.
Nos exemplos anteriores, as anotações tinham a
função de qualificar os valores que as variáveis po-
deriam conter. Porém, podem ser pensadas outras
formas de qualificar o tipo File: @Open, @Localized,
@NonNull, etc; também pode ser pensada na aplica-
ção dessas anotações qualificando outros tipos, como
por exemplo: @Encrypted String. Devido ao fato das
anotações serem independentes do sistema de tipos
do Java, os conceitos expressos através delas podem
ser reutilizadas de muitas formas.
Mas como essas anotações poderiam ser automa-
ticamente verificadas? Intuitivamente, algumas ano-
tações são subtipos de outras anotações e suas apli-
cações podem ser verificadas em relação aos tipos.
Considere a vulnerabilidade ao ataque de Injeção de
SQL, causado pela execução de sentenças SQL modi-
ficadas maliciosamente pelo usuário. Pode-se pensar
em um tipo de dados classificado como @MaybeTain-
ted, indicando que o dado pode ter sido adulterado,
ou @Untainted, indicando que o dado está garantida-
mente livre de adulteração, pois não foi diretamente
informado pelo usuário.
@MaybeTainted String userInput;
@Untainted String dbQuery;
A anotação @MaybeTainted pode ser vista como
um supertipo da anotação @Untainted. Existem vá-
rias maneiras de pensar nessa relação. Primeiro, o
conjunto de valores que podem ter sido adulterados
mente não foram adulterados (um valor que não foi
adulterado pode ser um elemento desse superconjun-
to). Dessa forma, a anotação @Untainted fornece uma
garantia maior que @MaybeTainted. Na prática, essa
eMag | Java: Presente e Futuro 17
 tipagem poderia funcionar da seguinte forma:
userInput = dbQuery; // OK
dbQuery = “SELECT FROM * WHERE “ + userInput; // erro de
tipo!
Nesse exemplo, a primeira linha não contém ne-
nhum problema, pois userInput supõe que o valor
atribuído pode ter sido adulterado, mesmo que esse
não seja o caso. Por outro lado, essa tipagem revela
um erro na segunda linha, pois está atribuindo um
valor que pode ter sido adulterado a uma variável
que contém essa restrição.
O framework Checker
O Checker é um framework que faz verificações de
anotações em Java. Lançado em 2007, esse framework
é um projeto de código aberto encabeçado pelo sub-li-
der da especificação JSR 308, professor Michael Ernst.
O Checker vem com um conjunto padrão de anota-
ções e verificadores de falhas, tais como: NullPointe-
rException, incompatibilidade no uso de unidades de
medidas, vulnerabilidades de segurança, problemas
de concorrência, entre outros. Por ser um verificador
que utiliza mecanismos formais de verificação de ti-
pagem baseado em lógica, ele é capaz de reconhecer
falhas potenciais que verificadores baseados em heu-
rísticas não detectam. O framework usa uma API de
compilador que detecta as falhas durante a compila-
ção. Outra característica é que ele é estensível, o pró-
prio desenvolvedor pode criar rapidamente os seus
verificadores de anotações para detectar problemas
específicos da aplicação em questão.
A meta do Checker é detectar falhas sem que o
desenvolvedor tenha que escrever muitas anotações.
Isso é feito principalmente através de duas funciona-
lidades apelidadas como: padrões mais inteligente e
controle de fluxo sensíveis. Por exemplo, durante o
processo de verificação de falhas por ponteiros nu-
los, o verificador assume que os parâmetros de um
método não são nulos por padrão. O verificador pode
também utilizar condicionais para determinar quan-
do uma atribuição de nulo é uma expressão válida.
void nullSafe(Object nonNullByDefault, @Nullable Object
mightBeNull){
nonNullByDefault.hashCode(); // OK, devido ao padrão
mightBeNull.hashCode(); // Falha!
if (mightBeNull != null){
mightBeBull.hashCode(); // OK, devido ao padrão
}
}
18 InfoQ Brasil
Na prática, os padrões e o controle de fluxo sensí-
veis significam que o desenvolvedor raramente terá
que escrever anotações no corpo dos métodos, pois o
verificador é capaz de inferir e verificar as anotações
automaticamente. Mantendo a semântica das anota-
ções fora do compilador oficial do Java garante que
ferramentas de terceiros e os próprios desenvolvedo-
res tomem as suas decisões. Isso permite que a veri-
ficação de erros possa ser personalizada conforme as
necessidades de cada projeto.
A habilidade de definir suas próprias anotações
também permite que seja considerada a verificação
de subtipos específicos do domínio de negócio. Por
exemplo, em um sistema financeiro, as taxas de ju-
ros usam frequentemente porcentagens enquanto a
diferença entre taxas utiliza ponto base (1/100 de 1%).
Com um framework de verificação de unidades po-
dem ser definidas as anotações @Percent e @Basis-
Point para garantir que não há confusão no uso dos
dois tipos:
BigDecimal pct = returnsPct(...); // anotado para devolver @Percent
requiresBps(pct); // erro: requer @BasisPoints
No exemplo apresentado, devido ao fato do Che-
cker ser sensível ao fluxo de controle, sabe-se que
pct é um @Percent BigDecimal quando é feita a cha-
mada para requiresBps(pct) com base em dois fatos:
returnsPct(...) é anotado para devolver um @Percent
BigDecimal e pct não foi novamente atribuído antes
de chamar requireBps(...). Frequentemente, desenvol-
vedores usam convenções de nomes para tentar pre-
venir esses tipos de falha. O que o Checker faz é dar
ao desenvolvedor a garantia de que essas falhas não
existam, mesmo que o código mude e evolua.
O Checker já foi executado em milhões de linhas
de código, apontando centenas de falhas, mesmo em
código bem testado. Um dos exemplos mais interes-
sante aconteceu ao executá-lo com a biblioteca muito
utilizada Google Collections, agora Google Guava,
que revelou um possível NullPointerException que
não tinha sido detectado após vários testes e nem
após utilizar ferramentas heurísticas de análise está-
tica de falhas.
Resultados assim foram obtidos sem fazer muitas
alterações no código existente. Na prática, verificar
uma propriedade com o Checker requer somente 2
ou 3 anotações para uma centena de linhas de código.
Para aqueles que utilizam o Java 6 ou 7, também é
possível usar o Checker para melhorar a qualidade
do código. As anotações podem ser escritas em co-
mentários, tal como:
/* @NonNull */ String aString
Historicamente, a razão disso é que o Checker foi
desenvolvido junto com a JSR 308, que teve início em
2006.
Apesar do Checker ser o melhor framework para
fazer verificação de falhas utilizando anotações, ele
não é o único atualmente. Tanto o Eclipse quanto o
IntelliJ dão suporte a esse tipo de anotação:

POSSUEM SUPORTE
Checker Framework Suporte completo, incluindo anota-
ções em comentários.
Eclipse Suporte à verificação de valores não
nulos.
IntelliJ IDEA Podem ser escritos inspecionadores
personalizados, suporte à verificação
de valores não nulos.
NÃO POSSUEM SUPORTE
PMD
Coverity
Check Style Sem suporte para Java 8.
Find Bugs Sem suporte para Java 8.

Aumentando a produtividade com anotações de tipo

A ideia inicial por trás das anotações de tipo era a verificação de falhas. Contudo, ainda haviam muitas apli-
cações convincentes desse tipo de anotação em ferramentas de produtividade. Para entender um pouco melhor
o porquê, considere os seguintes exemplos de como as anotações são usadas

Programação Orientada a Aspectos @Aspect, @Pointcut, etc.

Injeção de Dependência @Autowired, @Inject, etc.
Persistência @Entity, @Id, etc.

As anotações são especificações declarativas para
informar como as ferramentas devem gerar código
ou arquivos auxiliares e como as ferramentas devem
se comportar durante a execução do programa. O uso
das anotações desse modo pode ser considerado uma
forma de metaprogramação. Alguns frameworks, tal
como o Lombok, tiram vantagem da metaprograma-
ção com anotações ao extremo, resultando em um có-
digo que mal parece Java.
Considere a Programação Orientada a Aspectos
(Aspect Oriented Programming - AOP). A AOP aju-
da na separação de propriedades ortogonais de uma
aplicação, tais como log e autenticação, daquelas rela-
cionadas às regras de negócio. Com a AOP é possível
executar um aplicativo em tempo de compilação que
adiciona código ao programa com base em um con-
junto de regras. Por exemplo, pode ser definida uma
regra que automaticamente faz autenticação com
base no tipo anotado:
void showSecrets(@Authenticated User user){
// Inserido automaticamente pela AOP:
if (!AuthHelper.EnsureAuth(user)) throw . . .;
}
Como antes, a anotação está qualificando o tipo.
Ao invés de verificar as anotações em tempo de com-
pilação, a AOP é usada para fazer a verificação em
tempo de execução automaticamente. Esse último

eMag | Java: Presente e Futuro 19

 exemplo mostra a anotação de tipo sendo usada para
dar um controle maior sobre como e quando a AOP
modifica o programa.
O Java 8 também dá suporte às anotações de tipo
em declarações locais que são persistidas nos arqui-
vos de bytecode. Isso cria novas oportunidades para
se ter uma AOP mais granular. Por exemplo, para
incluir código de rastreamento de uma forma mais
granular:
// Faz o rastreamento de todas as chamadas ao objeto ar
@Trace AuthorizationRequest ar = . . .;
Novamente, as anotações de tipo dão maior con-
trole ao se fazer metraprogramação com AOP. A In-
jeção de Dependência é uma história similar. Com o
Spring 4, é finalmente possível usar generics como
qualificador:
@Autowired private Store<Product> s1;
@Autowired private Store<Service> s2;
Com generics é possível eliminar a necessidade
introduzir classes como ProductStore e ServiceStore
ou usar regras mais frágeis de injeção baseada em
nomes.
Com anotações de tipo, não é difícil imaginar que
um dia o Spring permita usá-las para controlar a inje-
ção da seguinte forma:
@Autowired private Store<@Grocery Product> s3;
Esse exemplo mostra um tipo anotado servindo
como um mecanismo de separação de interesses, fa-
vorecendo para que a hierarquia de tipos do projeto
seja mais concisa. Essa separação só é possível por-
que as anotações de tipo são independentes do siste-
ma de tipagem do Java.
A estrada à frente
Como apresentado, as anotações de tipo podem
ser usadas tanto para detectar como prevenir erros
em programas e também para aumentar a produti-
vidade. Contudo, o potencial real das anotações de
tipos está em combinar a verificação de erros e a me-
taprogramação para dar suporte aos novos paradig-
mas de desenvolvimento.
A ideia básica é construir ambientes de execução
e bibliotecas que alavanquem a abordagem de criar
programas automaticamente mais eficientes, parale-
los ou seguros e que façam com que os desenvolvedo-
res usem as anotações corretamente.
20 InfoQ Brasil
Um bom exemplo dessa abordagem é o framewok
EnerJ, de Adrian Sampson, para computação com
eficiência energética utilizando a computação aproxi-
mada. EnerJ baseia-se na observação de que em certas
ocasiões, tal como o processamento de imagens em
dispositivos móveis, faz sentido reduzir a precisão
para poupar energia. Um desenvolvedor usando o
EnerJ pode anotar um dado que não é crítico usan-
do a anotação @Approx. Com base nessa anotação, o
ambiente de execução do EnerJ usa vários atalhos ao
manipular esse dado. Por exemplo, pode ser utiliza-
do um hardware de cálculos aproximados de baixo
consumo de energia para armazenar e fazer cálculos.
Contudo, tendo dados aproximados se movendo pelo
programa pode ser perigoso, e nenhum desenvolve-
dor vai querer controlar o fluxo afetado por esse dado
aproximado. Portanto, o EnerJ usa o Checker para ga-
rantir que os dados aproximados não sejam utiliza-
dos em sentenças de controle de fluxo, por exemplo,
em sentenças condicionais como ifs.
Mas as aplicações dessa abordagem não são limi-
tadas a dispositivos móveis. Em finanças, frequen-
temente há um conflito entre precisão e velocidade.
Nesses casos, o ambiente de execução pode decidir
entre usar um algoritmo de Monte Carlo para o cálcu-
lo de caminhos, um critério de convergência ou mes-
mo processar algo em um hardware especializado
com base nas demandas atuais ou na disponibilidade
de recursos.
A beleza desse abordagem é que a preocupação de
como uma execução deve ser feita fica fora da lógica
de negócio central da aplicação, que descreve o que
deve ser feito.
Conclusão
No Java 8, as anotações podem ser usadas em qualquer tipo, incrementando a capacidade de escrever anota-
ções em declarações. As anotações por sí próprias não afetam o comportamento do programa. Contudo, utili-
zando ferramentas como o Checker, é possível utilizá-las para verificar automaticamente a ausência de falhas e
aumentar a produtividade com metaprogramação. Enquanto ainda levará algum tempo para que as ferramentas
existentes obtenham total vantagem das anotações de tipos, agora é hora de começar a explorar como as anota-
ções de tipos podem melhorar tanto a qualidade do software desenvolvido quanto a produtividade.

Sobre o Autor

Todd Schiller é diretor da FinLingua, uma companhia de consultoria

e desenvolvimento de software para a área financeira. A prática de
consultoria da FinLingua ajuda equipes de desenvolvimento a adotar
uma linguagem específica de domínio, metraprogramação e técnicas
de análise de programas. Todd é um membro ativo da comunidade de
pesquisa em engenharia de software; sua pesquisa em especificação e
verificação tem sido apresentada nas principais conferências interna-
cionais, incluindo ICSE e OOPSLA.

eMag | Java: Presente e Futuro 21

JAVA 8: DESMISTIFICANDO LAMBDAS
por Simon Ritter, traduzido por Rafael Sakurai
O artigo destaca os pontos principais da palestra “Lambdas & Streams” que Simon Ritter apresentou no QCon London 2014. Ele explica o que são as
expressões Lambdas, interface funcional, referência de métodos, Streams, operações de agregação e diversos exemplos
S
e perguntarmos aos desenvolvedores Java sobre o
Java 8, teremos diversas respostas bem animadas,
especialmente sobre o uso das expressões lambda.
Mas após uma conversa mais honesta, encontramos
um fervor misturado com um pouco de receio em relação
às novas e misteriosas APIs disponíveis na Web. Simon
Ritter revelou alguns dos mistérios na apresentação sobre
lambdas na conferência QCon London 2014.
A seguir, temos um trecho de código Java que ilustra
um padrão comum:
Nota: As partes em vermelho são aquelas que estamos
interessados; e as partes em azul representam código re-
22 InfoQ Brasil
petitivo.
Neste problema, queremos encontrar a maior nota em
uma coleção de estudantes. Usamos um idioma comum
de iteração externa para percorrer e comparar cada ele-
mento da coleção.
Mas há algumas desvantagens no código. Em primeiro
lugar, a iteração externa significa que os desenvolvedores
são responsáveis pela implementação (programação im-
perativa), e como é usado um único loop, definimos que
a execução do código será de modo sequencial. Se qui-
sermos otimizá-lo, não poderíamos facilmente segmentar
em um conjunto de execução de instruções em paralelo.
Em segundo lugar, a variável highestScore é mutável
e não é thread-safe. Então, mesmo que quiséssemos que-
brá-lo em múltiplas threads, precisaríamos adicionar um
lock (bloqueio) para prevenir race conditions (condições
de concorrência), que por sua vez podem introduzir pro-
blemas de desempenho.
Agora, se quisermos agir de modo mais inteligente,
podemos mudar um pouco mais a implementação em
direção ao estilo funcional utilizando uma classe interna
anônima:

Nessa implementação, eliminamos o estado mu-
tável e passamos o trabalho da interação para a bi-
blioteca. Estamos encadeando uma sequência de cha-
madas de métodos para aplicar a operação em uma
expressão “Olhe para todos os meus estudantes e fil-
tre apenas aqueles que se graduaram em 2011”.
A classe interna anônima implementa a interface
Predicate (ela contém um método, aceita um parâme-
tro e retorna um valor booleano) com o método cha-
Pense nas expressões lambda como um método,
no sentido de que ele aceita parâmetros, tem corpo e
retorna um tipo estático.
Nesse exemplo, usamos as expressões lambda
para obter o mesmo algoritmo que determina qual a
maior nota, como nos exemplos anteriores. Vejamos
em detalhes.
Primeiro, criamos um Stream a partir de uma Col-
lection. O método stream é novo na interface Collec-
tion e funciona de forma parecida com um Iterator
embutido (veremos em mais detalhes logo adiante).
O stream prepara os resultados da coleção, que en-
tão passa para o método filter, descrevendo “como”
as partes serão filtradas usando a expressão lambda
que compara o ano de graduação dos estudantes com
mado “op”, que simplesmente compara o ano de gra-
duação do estudante com 2011 e retorna o resultado.
Enviaremos o resultado (todos os estudantes gra-
duados em 2011) para o método “map”, que usará ou-
tra classe interna anônima para chamar um método
da interface de mapeamento com seu único método
“extract” para extrair o dado que queremos (chaman-
do o método getScore). Então passaremos esse resul-
tado, que é um conjunto de notas de todos estudantes
graduados em 2011, para o método “max”, que enfim
entregará o maior valor a partir do conjunto de re-
sultados.
Usando essa abordagem, tratamos toda a intera-
ção, filtro e acúmulo com o uso da biblioteca, sem
precisar fazer isso de forma explícita. Isso não somen-
te simplifica a implementação, como também elimina
o compartilhamento de estado, deixando mais fácil
pedir ao código da biblioteca para decompor a imple-
mentação em diversas sub tarefas e alocá-lo em di-
ferentes threads para serem executadas em paralelo.
Em muitos casos, também executamos uma avaliação
posterior, economizando ainda mais tempo.
Então, uma abordagem que usa classe interna
anônima é rápida e thread-safe, mas atente-se para
as cores do código fonte. Note que a quantidade em
azul é maior do que em vermelho, indicando código
repetitivo.
Então, entram em cena as expressões lambda!
2011.
Note que não há um retorno explicito. Simples-
mente dizemos “Compare o ano de graduação com
2011” e o compilador deduz que destina-se a interface
Predicate (que tem um único método que necessita de
uma assinatura com um retorno do tipo booleano).
O método map é processado de forma similar, usan-
do uma expressão lambda, passando um estudante S
como parâmetro e mapeando (como um tradutor) seu
valor de retorno, que é a nota (score) do estudante. O
método map não deve ser confundido com o java.util.
Map que usa pares de chave-valor. O método map da
classe Stream retorna uma nova instância do Stream
contendo os resultados da operação aplicada para to-
dos os elementos da Stream de entrada, produzindo,
eMag | Java: Presente e Futuro 23
 nesse caso, um Stream com todas as notas.
Usando lambdas implementamos o mesmo algo-
ritmo com muito menos código. É mais compreensí-
vel, portanto menos propenso a erros, e como visto,
ele pode ser alterado para um algoritmo paralelo uma
vez que não há compartilhamento de estado.
Como Ritter disse em sua apresentação:
“As expressões Lambda representam uma função
anônima. Então, elas são como métodos, mas não são
realmente um método. Elas são como funções anô-
nimas no sentido de que elas tem as mesmas funcio-
nalidades de um m étodo, mas elas não são métodos
porque não estão associadas com uma classe. Se pen-
sar no Java como programamos hoje, criamos classes
e classes têm métodos. Portanto o método tem uma
classe associada a ele. No caso das expressões Lambd
dentro de uma expressão Lambda e ela tem um corpo,
que defini o que ela fará. Também é possível fazer as
mesmas coisas que um método: pode agrupar instru-
ções; pode usar chaves e ter múltiplas instruções sem
nenhum problema. A coisa mais importante sobre isso
é que agora permite usar uma maneira simples de ter
um procedimento parametrizado, não apenas valores
parametrizados.”
Ritter ampliou esse conceito apontando que uma
vez que uma lambda é uma função sem uma classe,
então a palavra-chave “this” não se refere a própria
lambda, mas sim a classe na qual foi declarada. Isso
distingue de uma classe interna anônima, na qual
“this” refere-se a própria classe interna.
É útil olhar para as decisões de implementações
que os designers da linguagem fizeram para desen-
volver os lambdas.
Olhando para o Java como um todo, há muitas in-
terfaces que possuem apenas um método.
Vamos definir uma interface funcional como uma
interface com exatamente um método abstrato, por
exemplo:
interface Comparator<T> { boolean compare(T x, T y); }
interface FileFilter { boolean accept(File x); }
interface Runnable { void run(); }
interface ActionListener { void actionPerformed(…); }
interface Callable<T> { T call(); }
Uma expressão Lambda permite definir uma inter-
face funcional (novamente, um método abstrato) que
24 InfoQ Brasil
o compilador identifica pela estrutura. O compilador
pode determinar a interface funcional representada a
partir de sua posição. O tipo de uma expressão lamb-
da é o da interface funcional associada.
Como o compilador conhece os locais que são usa-
dos uma expressão lambda, é possível determinar
muito sobre essa expressão. Portanto como o compi-
lador sabe o tipo da interface funcional, então pode
inferir os outros tipos necessários.
Mas, Ritter avisa:
“Um ponto de atenção é que embora não tenhamos
explicitamente colocado o tipo da informação lá, isso
não significa que está usando uma tipagem dinâmica
no Java. Nunca faríamos isso, é desagradável e ruim.
Então, o que fazemos é dizer que isso ainda é uma tipa-
gem muito estática, mas com menos digitação.”
Ainda segundo Ritter, uma coisa que diferencia as
expressões lambda dos closures, é que ao contrário
dos closures, as lambdas não podem acessar as vari-
áveis que estão fora da expressão lambda, exceto as
variáveis que são efetivamente final, isso significa que
embora a variável não precisa da palavra-chave final
(ao contrário de uma classe interna), no entanto o seu
valor não pode ser reatribuído.”
Referência de métodos
A sintaxe da referência de método é outra nova
funcionalidade da expressão lambda. É um atalho
que permite reutilizar um método basicamente como
uma expressão Lambda. Podemos fazer coisas como:
FileFilter x = f -> f.canRead();
Essa sintaxe diz para o programa criar um FileFil-
ter que filtra os arquivos com base em uma proprie-
dade comum – nesse caso, se o arquivo pode ser lido.
Note que nesse exemplo, nunca mencionamos que f é
um arquivo; o compilador infere através da assinatu-
ra do único método no FileFilter:
boolean accept(File pathname);
Podendo ser simplificado ainda mais usando a
nova notação do Java 8 “::”.
FileFilter x = File::canRead;
 Essas sintaxes são completamente equivalentes.
Para chamar um construtor de forma análoga,
pode ser utilizado a sintaxe “::new”. Por exemplo, se
tivermos uma interface funcional como:
interface Factory<T> {
T make();
} boilerplate ao código fonte.
Então, podemos dizer:
Factory<List<String>> f = ArrayList<String>::new;
Isso é equivalente a:
Factory<List<String>> f = () -> return new ArrayList<String>();
E agora, quando f.make() é chamada, será retorna-
do um novo ArrayList<String>.
Usando as interfaces funcionais, o compilador
pode deduzir muitas coisas sobre a tipagem e inten-
ção, como demonstrado nesses exemplos.
Evolução da biblioteca
Uma das vantagens das lambdas e expressão de
códigos como dados é que, como visto, as bibliotecas
existentes foram atualizadas para aceitar lambdas
como parâmetros. Isso introduz alguma complexida-
de: como introduzir métodos na interface sem que-
brar as implementações das interfaces que já existem?
Para fazer isso, o Java introduz o conceito de mé-
todos de extensão, também conhecido como defender
métodos ou métodos default (padrão).
Vamos explicar usando um exemplo. O método
stream foi adicionado na interface Collection para
fornecer um suporte básico ao lambda. Para adicio-
nar o método stream na interface sem quebrar as im-
plementações existentes da Collection de todo mun-
do, o Java adicionou o stream como um método da
interface, fornecendo uma implementação padrão:
interface Collection<E> {
default Stream<E> stream() {
return StreamSupport.stream(spliterator());
} lateral. (Um efeito colateral significa que talvez não
} consiga retornar um resultado, mas ao invés disso,
Então, agora temos a opção de implementar o mé-
todo stream ou se preferir usar a implementação pa-
drão fornecida pelo Java.
Operações de agregação
Operações de negócios frequentemente envolvem
agregações como: encontrar a soma, máximo, ou mé-
dia de um conjunto de dados, ou grupo de alguma
coisa. Até agora, tais operações são normalmente exe-
cutadas com loops de interação externa, como disse-
mos, nos restringindo das otimizações e adicionando
As Streams do Java SE 8 tem como objetivo resol-
ver estes problemas. Nas palavras de Ritter:
“Um stream é a maneira de abstrair e especificar
como processar uma agregação. Ele não é uma estru-
tura de dados. Na realidade é uma maneira de tratar os
dados, mas define uma nova estrutura de dados, e in-
teressantemente pode tanto finito quanto infinito. En-
tão, é possível criar um stream de, digamos, números
aleatórios e não precisa mais ter um limite. É aqui que,
algumas vezes, as coisas ficam um pouco confusas. Re-
flita sobre a seguinte questão: - Se tenho um stream
infinito, posso continuar processando os dados para
sempre. Como faço para parar o que estou fazendo
com os dados?”
A resposta é que potencialmente não será finaliza-
do. É possível fazer facilmente um trecho de código
usando streams que continua para sempre, como se
fosse um loop “while(true);” infinito. Ele é como um
Stream: se usar um Stream infinito, ele pode nunca
terminar. Mas também é possível fazer um Stream
parar - digamos, para fornecer um Stream infinito de
números aleatórios, mas com um ponto de parada.
Assim o Stream vai parar e o programa pode conti-
nuar sua execução.
O Stream fornece um pipeline (sequência) de da-
dos com três componentes importantes:
1. Uma fonte de dados;
2. Zero ou mais operações intermediarias, forne-
cendo um pipeline de Streams;
3. Uma operação terminal(final) que pode realizar
duas funções: criar um resultado ou um efeito co-
consiga imprimir o valor.)
eMag | Java: Presente e Futuro 25
 Nesse exemplo, iniciamos com uma Collection de
“transações” e queremos determinar o preço total de
todas as transações que foram realizadas por com-
pradores de Londres. Obtemos um stream a partir da
Collection de transações.
Depois obtemos um stream a partir da Collection
de transações. Então, aplicamos uma operação de fil-
tro para produzir um novo Stream com os comprado-
res de Londres.
A seguir, aplicamos a operação intermediaria
mapToInt para extrair os preços. E finalmente, aplica-
mos a operação final de soma para obter o resultado.
Do ponto de vista da execução, o que aconteceu
aqui é que o filtro e o método de map (a operação
intermediaria) não realizaram um trabalho compu-
tacional. Foram apenas responsáveis por configurar
o conjunto das operações, e a computação real é exe-
cutada posteriormente, postergado até chamar a ope-
ração final – nesse caso a soma (sum) – que faz todo
trabalho acontecer.
Fontes de stream
Há diversas formas de obter um Stream. Muitos
métodos estão sendo adicionados a API de Collection
(usando a extensão de métodos nas interfaces).
Através de uma List, Set, ou Map.Entry é possível
chamar um método de Stream que retorna uma Stre-
am com o conteúdo da coleção.
Um exemplo é o método stream(), ou parallelStre-
am(), que internamente a biblioteca usa o framework
de fork/join para decompor as ações em diversas sub-
tarefas.
Há outras maneiras de obter um stream:
• Fornecer um array para o método stream() da
classe Arrays;
• Chamar o método Stream.of(), um método está-
tico da classe Stream;
• Chamar um dos novos métodos estáticos para
retornar um stream em particular, por exemplo:
»» IntStream.range(), fornecendo um índice de
inicio e fim. Por exemplo, IntStream.range(1, 10)
gera um stream de 1 a 9 com incremento de 1
26 InfoQ Brasil
em 1 (IntRange.rangeClosed(1, 10) gera um stre-
am de 1 a 10);
»» Files.walk() passando um caminho e algum
parâmetro de controle opcional que retorna um
stream de arquivos individuais ou subdiretó-
rios;
»» Implementar a interface java.util.Spliterator
para definir sua própria maneira de criar um
Stream. Para mais informações sobre o Splite-
rator consulte o Javadoc do SE 8 fornecido pela
Oracle.
Operações de finalização de Stream
Depois de encadearmos todos esses streams, po-
demos especificar uma operação de finalização para
executar as pipeline e todas as operações (sequencial-
mente ou em paralelo) e produzir os resultados finais
(ou efeitos colaterais).
int sum = transactions.stream().
filter(t -> t.getBuyer().getCity().equals(“London”)). //Lazy
mapToInt(Transaction::getPrice). //Lazy
sum(); //Executa o pipeline
Inteface Iterable
Essa é uma velha conhecida dos dias do Java 1.5, ex-
ceto que agora tem um método forEach() que aceita
um Consumer, que aceita um simples argumento e
não retorna valor e produz um efeito colateral. Mas
continua sendo uma interação externa e a melhor for-
ma de obter um lambda é o método map().
Exemplos:
Ritter conclui a apresentação com alguns exemplos
uteis, que estão listados a seguir com comentários ex-
plicativos. (As linhas em negrito indicam o especial
uso demonstrado em cada exemplo).
Exemplo 1. Converter palavras para maiúsculo:
List<String> output = wordList.stream().
// Mapa de toda a lista de String em maiúsculo.
map(String::toUpperCase).
// Converte o stream para uma lista.
collect(Collectors.toList());
Exemplo 2. Procurar as palavras
com tamanho par na lista:
List<String> output = wordList.
stream().
//Seleciona somente as palavras com tamanho par.
filter(w -> (w.length() & 1 == 0).
collect(Collectors.toList());
Exemplo 3. Contar as linhas de um arquivo:
long count = bufferedReader.
// Recebe um stream com linhas individuais.
Esse é o novo método do
// bufferedReader que retorna um stream<string>.
lines().
// Conta os elementos do stream de entrada.
count();
Exemplo 4. Juntar as linhas 3 e 4 em uma única String:
String output = bufferedReader.
lines().
// Pula as duas primeiras linhas.
skip(2).
// limita a stream a apenas as próximas duas linhas.
limit(2).
// Concatena as linhas.
collect(Collectors.joining());
Exemplo 5. Encotrar o tamanho da linha mais longa
em um arquivo:
int longest = reader.lines().
mapToInt(String::length).
// cria um novo stream com o tamanho das strings mapeando
// a atual String ao tamanho correspondente.
max().
// Coleta o maior elemento do stream de tamanho (como
uma optionalInt)
getAsInt();
// Atualiza o OptionalInt com um int.
Exemplo 6. Coleção de todas as palavras do arquivo
em uma lista:
List<String> output = reader.
lines().
flatMap(line -> Stream.of(line.split(REGEXP))).
// Recebe um stream de palavras de
// todas as linhas.
filter(word -> word.length() > 0).
// Filtra as Strings vazias.
collect(Collectors.toList());
// Cria a lista de retorno.
Exemplo 7. Retorna a lista de palavras
minúscula em ordem alfabética:
List<String> output = reader.lines().
flatMap(line -> Stream.of(line.split(REGEXP))).
filter(word -> word.length() > 0).
map(String::toLowerCase).
// Atualiza o Stream da fonte com o Stream de
// letras minúsculas.
sorted().
// Atualiza o stream com a versão ordenada.
collect(Collectors.toList());
// Cria e retorna uma Lista
eMag | Java: Presente e Futuro 27
 Conclusão
Simon Ritter conclui a apresentação declarando:

“O Java precisa das expressões lambda para facilitar a vida do desenvolvedor. As expressões lambdas eram ne-
cessárias para a criação dos Streams e também para implementar a ideia de passagem de comportamento como a
passagem de valor. Também precisávamos ampliar as interfaces existentes, com o uso das extensões de métodos do
Java SE 8, e que resolve o problema da retro compatibilidade. Isso permite fornecer a ideia de operações em lote na
Collections e permite fazer coisas que são mais simples, e de um modo mais legível. O Java SE 8 está basicamente
evoluindo a linguagem; evoluindo as bibliotecas de classes e também as maquinas virtuais ao mesmo tempo.”

O Java 8 está disponível para download e há um bom suporte a lambda em todos as principais IDEs. Sugiro
que todos os desenvolvedores Java façam o download e usem o Projeto Lambda.

Sobre o Autor

Simon Ritter é o diretor do Evangelismo da tecnologia Java na

Oracle Corporation. Ritter trabalha com negócios de TI desde 1984
e é bacharel de Ciência graduado em Física pela universidade de
Brunel no Reino Unido.

28 InfoQ Brasil
QUÃO FUNCIONAL É O JAVA 8?
por Ben Evans, traduzido por Roberto Pepato
Tem sido falado que o Java 8 trouxe a Programação Funcional para o Java. Neste artigo, Ben Evans discute o que significa ser funcional. Olhando
a evolução do Java — em particular o seu sistema de tipos, é possível ver como os novos recursos do Java 8, especialmente as expressões lambda,
mudam o panorama e fornecem alguns benefícios fundamentais para o estilo de programação funcional.

T
em-se falado muito sobre como
“o Java 8 trouxe a Programação
Funcional para o Java” - mas, o
que isso realmente quer dizer?
Neste artigo, será apresentado o
que significa ser funcional para uma
linguagem, ou para um estilo de
programação. Olhando a evolução
de Java, em particular o seu sistema
de tipos (type system), é possível ver
como os novos recursos do Java 8,
especialmente as expressões lamb-
da, mudam este cenário e oferecem
alguns dos principais benefícios da
programação funcional.
O que é uma linguagem de
programação funcional?
Em sua essência, uma linguagem
de programação funcional é aquela
que trata da mesma forma tanto o có-
digo como os dados. Isto significa que
uma função deve ser um valor de pri-
meira classe na linguagem e deve po-
der ser atribuída a variáveis, passada
como parâmetro para funções, entre
outras funcionalidades.
De fato, muitas linguagens funcio-
nais vão ainda mais longe que isso
e enxergam a computação e os algo-
ritmos como estruturas mais funda-
mentais que os dados que operam.
Algumas destas linguagens buscam
desmembrar o estado do programa de
suas funções (de uma forma que pare-
ce contrária ao desejo das linguagens
orientadas a objetos, que normalmen-
te buscam manter algoritmos e dados
integrados).
Um exemplo seria a linguagem de
programação Clojure. Apesar de exe-
cutar sobre a Java Virtual Machine,
que é baseada em classes, a Clojure é
fundamentalmente uma linguagem
funcional e não expõe diretamente as

eMag | Java: Presente e Futuro 29

classes e objetos na linguagem de alto
nível (embora exista uma boa intero-
perabilidade com Java).
Uma função Clojure, como a fun-
ção de processamento de log apre-
sentada a seguir, é um cidadão de
primeira classe na linguagem e não
precisa ser declarada em uma classe
para existir.
(defn build-map-http-entries [log-file]
(group-by :uri
(scan-log-for-http-entries log-file)))
A programação funcional é útil
quando os programas são escritos em
termos de funções que sempre retor-
nam a mesma saída para uma entrada
específica (independente de qualquer
outro estado presente no programa
em execução) e que não causem efei-
tos colaterais ou alterem quaisquer
estados do sistema. Funções que obe-
decem a esta restrição as vezes são
chamadas de funções “puras” e se
comportam da mesma forma que as
funções matemáticas.
A grande vantagem das funções
puras é que são mais fáceis de enten-
der, pois seu funcionamento não de-
pende de estado externo. As funções
podem ser facilmente combinadas
entre si — e isto pode ser observado
em estilos de fluxos de trabalho dos
desenvolvedores como no estilo Ler,
Executar, Imprimir e Laço (Read, Exe-
cute, Print, Loop - REPL), comum a
dialetos Lisp e outras linguagens com
forte herança funcional.
Programação funcional em
linguagens não funcionais
A característica de uma lingua-
gem ser ou não funcional não é uma
condição binária — ao invés disto, as
linguagens existem em um espectro.
Em um dos extremos desta espectro
estão as linguagens que basicamente
forçam a programação funcional, fre-
quentemente proibindo estruturas de
dados mutáveis. Clojure é um exem-
plo de linguagem que não permite a
30 InfoQ Brasil
utilização de estruturas de dados mu-
táveis.
No entanto, existem outras lingua-
gens onde é comum escrever progra-
mas no estilo funcional, apesar da
linguagem não impor esta restrição.
Um exemplo seria o Scala, que é uma
mistura de linguagens orientadas a
objetos e funcional e permite utilizar
funções como valores, tais como:
val sqFn = (x: Int) => x * x
Mantendo a sintaxe de classes e
objetos que é muito próximas do Java.
No outro extremo, é possível es-
crever programas utilizando progra-
mação funcional em linguagens com-
pletamente não-funcionais, como é o
caso do C, desde que a disciplina de
programação adequada e as conven-
ções sejam mantidas.
Com isto em mente, a programação
funcional deve ser vista como uma
função de dois fatores — um que é
relevante para as linguagens de pro-
gramação e outro que é relevante para
programas escritos nesta linguagem:
1) Até que ponto a linguagem de
programação utilizada auxilia ou re-
força a programação funcional?
2) Como este programa específico
faz uso das características funcionais
fornecidas pela linguagem? Ele evita
utilizar recursos não-funcionais, tais
como estado mutável?
Java - um pouco de história
Java é uma linguagem com perso-
nalidade, otimizada para facilitar a
legibilidade, a acessibilidade aos pro-
gramadores iniciantes e para promo-
ver o suporte e a estabilidade a longo
prazo. Estas decisões de design têm
um custo, como exemplo a verbosida-
de e no sistema de tipos que pode as
vezes parecer inflexível quando com-
parado a outras linguagens.
No entanto, o sistema de tipos de
Java evoluiu, ainda que de forma rela-
tivamente lenta, ao longo da história
da linguagem. Vamos dar uma olhada
em algumas formas que a linguagem
assumiu ao longo dos anos:
O sistema de tipos original
do Java
O sistema de tipos original do Java
já possui mais de 15 anos. É simples e
claro, pois os tipos são de referência
ou primitivos. Os tipos de referências
(Reference Types) são classes, interfa-
ces ou arrays (vetores).
● As classes são a essência da pla-
taforma Java — uma classe é a uni-
dade básica de funcionalidade que a
plataforma Java vai carregar ou refe-
renciar — e todo o código destinado
para execução deve residir em uma
classe;
● As interfaces não podem ser di-
retamente instanciadas, ao invés dis-
so, uma classe que implementa a API
definida pela interface deve ser cons-
truída;
● Os arrays podem armazenar tan-
to tipos primitivos como instâncias de
classes, ou outros arrays;
● Todos os tipos primitivos são
definidos pela plataforma e o progra-
mador não pode definir novos tipos
primitivos.
Desde seus primeiros dias, o sis-
tema de tipos do Java vem insistindo
em um ponto muito importante, o de
que cada tipo deve possuir um nome
pelo qual possa ser referenciado. Esta
idéia é conhecida como tipagem no-
minativa (nominative typing) e o Java
é uma linguagem com forte tipagem
nominativa.
Mesmo as chamadas “classes anô-
nimas internas (anonymous inner
classes)” possuem um tipo pelo qual
o programador deve referenciá-las —
o tipo da interface que implementam:
Runnable r = new Runnable()
{ public void run()
{ System.out.println(“Hello World!”); } };\
Outra forma de se dizer isto é a de
que cada valor no Java é um tipo primi-
tivo ou a instância de alguma classe.

Alternativas a tipos nomeados
Outras linguagens não têm esse
fascínio por tipos nomeados. O Java
não tem um conceito equivalente ao
do Scala de um tipo que implementa
um método específico (de uma assina-
tura específica). No Scala, isto poderia
ser escrito da seguinte forma:
x : {def bar : String}
Lembre-se que no Scala indica-se o
tipo da variável à direita (após o : ),
então, isto é lido como: “x é de um tipo
que possui um método chamado bar
que retorna uma String”. Podemos
utilizar esta informação para definir
um método no Scala da seguinte for-
ma:
def showRefine(x : {def bar : String})
= { print(x.bar) }
e então, é possível definir um objeto
Scala desta forma:
object barBell { def bar = “Bell” }
e ao chamar o método
showRefine(barBell), o esperado será:
showRefine(barBell) Bell
Este é um exemplo de tipagem por
refinamento. Os programadores que
vêm de linguagens dinâmicas podem
estar familiarizados com o conceito
de duck typing (“se ele anda como um
pato e grasna como um pato, então é
um pato”). Tipagem por refinamen-
to estrutural (Structural refinement
typing) é um conceito similar, exceto
que duck typing trata de tipos em tem-
po de execução, enquanto os tipos de
refinamento estrutural funcionam em
tempo de compilação.
Em linguagens que possuem a ti-
pagem por refinamento estrutural de
forma completa, estes tipos refinados
podem ser utilizados em qualquer
lugar que o programador possa es-
perar - como o tipo de parâmetro de
um método. Em contraste, o Java não
possui esta categoria de tipagem (des-
considerando alguns casos extremos
e bizarros).
O sistema de tipos do Java 5
O lançamento do Java 5 trouxe três
principais novos recursos ao sistema
de tipos - tipos enumerados (enums),
anotações (annotations) e tipos genéri-
cos (generic types).
● Os tipos enumerados (enums)
são similares a classes em alguns as-
pectos, mas eles têm a propriedade
de restringir o número de instâncias
existentes, e cada instância é distinta
e especificada na descrição da classe.
Planejado originalmente para utili-
zação como constante de tipo seguro
(typesafe constant), ao invés da prá-
tica então comum de usar números
inteiros para constantes, a construção
enum também permite padrões adi-
cionais que são, por vezes, extrema-
mente úteis;
● As anotações (annotations) estão
relacionadas a interfaces — a palavra
reservada para declarar uma é @inter-
face — com o @ inicial indicando que
este é um tipo de anotação. Como o
nome sugere, elas são utilizadas para
anotar elementos de código Java com
informações adicionais que não afe-
tam seu comportamento. Anterior-
mente, o Java utilizava o conceito de
“interfaces de marcação” para forne-
cer uma forma limitada deste tipo de
metadado, mas as anotações são con-
sideravelmente mais flexíveis;
● Os tipos genéricos (generic
types) do Java fornecem tipos para-
metrizados - a ideia de que um tipo
pode funcionar como um “recipiente”
para objetos de outro tipo, sem levar
em conta as especificidades de exa-
tamente qual é o tipo que está sendo
contido. O tipo que se encaixa no reci-
piente é frequentemente chamado de
tipo de parâmetro (parameter type).
Dos recursos introduzidos no Java
5, os enums e as anotações oferecem
novas formas de tipos de referência
que exigem tratamento especial pelo
compilador e que são efetivamente
separados das hierarquias de tipos
existentes.
Os tipos genéricos adicionam uma
complexidade significativa ao sistema
de tipos do Java — muito em razão do
fato de serem um recurso puramente
de tempo de compilação. Isto exige
que o desenvolvedor Java esteja aten-
to aos sistemas de tipo em tempo de
compilação e em tempo de execução,
que são ligeiramente diferentes entre
si.
Apesar dessas mudanças, a insis-
tência do Java em tipos nominativos
permaneceu. Os nomes de tipo ago-
ra incluem List<String> (lido como:
“Lista de String”) e Map<Class<?>,
CachedObject> (“Map de Classe de
Tipo Desconhecido para CachedOb-
ject”), mas estes ainda são tipos no-
meados, e cada valor não primitivo
ainda é uma instância de uma classe.
Recursos introduzidos
no Java 6 e 7
O Java 6 foi essencialmente uma
versão para melhoria de desempenho
e de bibliotecas. As únicas mudanças
para o sistema de tipos foi a expansão
do papel das anotações e o lançamen-
to da capacidade de processamento
de anotação conectável (pluggable).
Isto não impactou a maioria dos de-
senvolvedores Java e não disponibili-
zou um sistema de tipos conectáveis
(pluggable type system) no Java 6.
O Java 7 não mudou materialmente
o sistema de tipos. Os únicos novos
recursos, todos de baixa relevância,
são:
● Pequenas melhorias na inferên-
cia de tipos do compilador javac;
● Tratamento de assinatura po-
limórfica - utilizado como um detalhe
de implementação para o recurso cha-
mado method handles - que, por sua
vez, foi utilizado para implementar
expressões lambda no Java 8;
● O Multi-catch fornece algumas
caracterísitcas de “tipos de dados al-
eMag | Java: Presente e Futuro 31
gébricos (algebraic data types)” - mas
são puramente internos ao javac e não
apresentam nenhuma consequência
real para o programador usuário fi-
nal.
O sistema de tipos do Java 8
Ao longo de sua história o Java foi
essencialmente definido por seu siste-
ma de tipos. Ele é fundamental para a
linguagem e tem mantido estrita ade-
rência aos tipos nominativos. De um
ponto de vista prático, o sistema de
tipos do Java não mudou muito entre
o Java 5 e Java 7.
A primeira vista, poderíamos es-
perar que o Java 8 mudasse isso. Afi-
nal de contas, uma expressão lambda
parece nos afastar da tipagem nomi-
nativa:
() -> { System.out.println
(“Hello World!”); }
Este é um método, sem um nome,
que não recebe parâmetros e retorna
void. Ainda é perfeitamente tipado de
forma estática, mas agora é anônimo.
Será que escapamos do Reino dos
Substantivos? Isto é realmente uma
nova forma de tipos para o Java?
A resposta é, talvez infelizmente,
não. A JVM, na qual o Java e outras
linguagens executam, é estritamente
associada ao conceito de classes. O
carregamento de classes (classloa-
ding) é fundamental para os modos
de segurança e verificação da plata-
forma Java. Simplificando, seria mui-
to, muito difícil conceber um tipo que
não fosse, de alguma forma, represen-
tado através de uma classe.
Ao invés de criar uma nova cate-
goria de tipos, as expressões lambda
do Java 8 são automaticamente con-
vertidas pelo compilador para uma
instância de uma classe. A classe em
questão é determinada por inferência
de tipos. Por exemplo:
Runnable r = () -> { System.out.println
(“Hello World!”); };
32 InfoQ Brasil
A lambda expression do lado di- como tipos (e sua localização no pa-
reito é um valor perfeitamente válido cote utilitário, ao invés do core da
no Java 8 - mas seu tipo é inferido do linguagem) demonstra o estrangu-
valor à esquerda - portanto, ela é na lamento que a tipagem nominativa
verdade um valor do tipo Runnable. impõe à linguagem Java e o quão dis-
Entretanto, note que se uma expres- tante a linguagem está da pureza de
são lamdba for utilizada de forma dialetos Lisp ou de outras linguagens
incorreta, ocorrerá um erro de compi- funcionais.
lação. A tipagem nominativa ainda é a Apesar de tudo o que foi exposto
forma utilizada pelo Java e até mesmo até aqui, este pequeno subconjunto
a introdução de lambdas não mudou do poder das linguagens funcionais
isso. pode muito bem ser tudo que a maio-
ria dos desenvolvedores realmente
precisa para suas atividades diárias
Quão funcional é o Java 8? de desenvolvimento. Para usuários
Finalmente, vamos voltar para avançados, outras linguagens (na
questão que fizemos no início do ar- JVM e em outros lugares) ainda exis-
tigo — “Quão funcional é o Java 8?” tem e, sem dúvida, continuam a pros-
Antes do Java 8, se o desenvolvedor perar.
quisesse escrever no estilo funcional,
seria necessário utilizar tipos ani-
nhados (geralmente classes internas
anônimas) como um substituto para
literais de funções (function literals).
As coleções de bibliotecas padrão não
ajudariam muito o código e a maldi-
ção da mutabilidade estaria sempre
presente.
As expressões lambda do Java 8
não transformam de forma mágica o
Java em uma linguagem funcional.
Em vez disso, seu efeito é o de criar
uma linguagem ainda imperativa,
com sistema de tipos ainda nomina-
tivos e que possui um maior suporte
às expressões lambda como literais
de funções. Simultaneamente, as me-
lhorias para as coleções de bibliotecas
permitiram que os desenvolvedores
Java começassem a adotar expressões
funcionais simples (como filter e map)
para tratar código que seria de alta
complexidade sem estes recursos.
O Java 8 demandou a introdução
de alguns novos tipos para represen-
tar os blocos de construção básicos de
fluxos de execução (pipelines) fun-
cionais — interfaces como Predicate,
Function e Consumer no pacote java.
util.function. Estas adições tornaram
o Java 8 capaz de permitir “programa-
ção ligeiramente funcional” — mas
sua necessidade de representá-los
JAVA 7 - CARACTERÍSTICAS QUE
VIABILIZAM O JAVA
por Ben Evans, traduzido por Diogo Carleto
Neste artigo, Ben Evans explora algumas funcionalidades do Java 7 que preparam o terreno para os novos recursos do Java 8.
É
uma verdade da indústria de
tecnologia que os desenvolve-
dores não podem ser mais feli-
zes do que quando há cerveja ou uma
oportunidade de reclamar sobre algo
oferecido.
Então, mesmo após os esforços de
Mark Reinhold e a equipe Java para
envolver a comunidade no roadmap
após a aquisição da Oracle (a decisão
Plano A / Plano B), muitos desenvol-
vedores Java sentiram que o Java 7
“não era bem um release”.
Neste artigo, tentamos refutar essa
tese, explorando as funcionalidades
do Java 7 que preparam o terreno para
as novas funcionalidades do Java 8.
8
Operador Diamante
O Java é muitas vezes criticado por
ser excessivamente verboso. Uma das
áreas mais comuns desta queixa está
na atribuição. No Java 6, somos força-
dos a escrever declarações de atribui-
ção como esta:
Map<String, String>
m = new HashMap<String, String>();
Esta declaração possui muita in-
formação redundante - devemos ser
capazes, de alguma forma, de fazer o
compilador entender mais sobre isso
sozinho, e não exigir que o programa-
dor seja tão explícito.
Na verdade, linguagens como Sca-
la fazem uma grande quantidade de
inferência de tipos a partir de expres-
sões e, de fato, declarações de atribui-
ção podem ser escritas tão simples
quanto isso:
val m = Map(“x” ->
24, “y” -> 25, “z” -> 26);
A palavra-chave val indica que
a variável não pode ser reatribuída
(como a palavra-chave final para va-
riáveis Java). Nenhum tipo de infor-
mação é especificado sobre a variável,
ao invés disso o compilador Scala exa-
mina o lado direito da declaração de
eMag | Java: Presente e Futuro 33
atribuição e determina o tipo correto
para a variável observando que valor
está sendo atribuído.
No Java 7, foram introduzidos al-
guns recursos de tipo de inferência li-
mitados, e declarações de atribuições
podem agora ser escritas da seguinte
forma:
Map<String, String> m = new HashMap<>();
As principais diferenças entre essa
forma e a do Scala, é que no Scala os
valores têm tipos explícitos e esses
são os tipos de variáveis inferidos. No
Java 7, o tipos das variáveis são explí-
citos e o tipo de informação sobre es-
ses valores é que é inferido.
Alguns desenvolvedores se quei-
xaram de que eles prefeririam a so-
lução Scala, mas acaba por ser menos
conveniente no contexto de uma das
principais características do Java 8 -
expressões lambda.
No Java 8, podemos escrever uma
função que adiciona 2 a um inteiro
dessa maneira:
Function<Integer, Integer> fn = x -> x + 2;
A interface Function é nova no Java
8 e está no pacote java.util.function,
juntamente com formas especializa-
das para tipos primitivos. Entretanto,
escolhemos essa sintaxe por ser muito
similar ao equivalente em Scala e per-
mitir que os desenvolvedores vejam
as similaridades mais facilmente.
Ao especificar explicitamente o
tipo de fn como uma Function que re-
cebe um argumento Integer e retorna
outro Integer, o compilador Java tem
condições de inferir o tipo do parâme-
tro x como Integer. Este é o mesmo pa-
drão que vimos na sintaxe diamante
no Java 7 - especificamos os tipos de
variáveis e inferimos o tipo de valo-
res.
Vamos olhar a expressão lambda
correspondente no Scala:
val fn = (x : Int) => x + 2;
Aqui temos que especificar explici-
tamente o tipo do parâmetro x. Como
não temos o tipo preciso de fn, então
não temos nada para inferir. A forma
de ler no Scala não é extremamente
difícil, mas a forma do Java 8 tem uma
certa clareza na sintaxe que lembra a
sintaxe diamante do Java 7.
Manipulador de Métodos
Os manipuladores de métodos são
simultaneamente o novo recurso mais
importante do Java 7 e o que é menos
provável de ser usado no dia-a-dia da
maioria dos desenvolvedores Java.
Um manipulador de método é uma
referência tipada de um método para
execução. Podem ser considerados
como “ponteiros para função segura”
(para desenvolvedores familiarizados
com o C/C++) ou como “A base do Re-
flection reimaginado pelos desenvol-
vedores modernos Java”.
Os manipuladores de métodos de-
sempenham um papel enorme na im-
plementação de expressões lambda.
Protótipos anteriores do Java 8 tinham
cada expressão lambda convertidas
em uma classe interna anônima em
tempo de compilação.
Vamos começar lembrando que a
expressão (ao menos no Java) lambda é
composta por uma assinatura de fun-
ção (que na API de manipuladores de
método será representado pelo objeto
MethodType) e um corpo, mas não ne-
cessariamente um nome de função.
Isto sugere que poderíamos con-
verter a expressão lambda em um
método sintético que tem a assinatura
correta e que contém o corpo do lamb-
da. Por exemplo a função:
Function<Integer, Integer> fn = x -> x + 2;
é convertido pelo compilador do Java 8
no método privado com esse bytecode:

private static java.lang.Integer lambda$0(java.lang.Integer);

descriptor: (Ljava/lang/Integer;)Ljava/lang/Integer;
flags: ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC
Code:
stack=2, locals=1, args_size=1
0: aload_0
1: invokevirtual #13 // Método java/lang/Integer.intValue:()I
4: iconst_2
5: iadd
6: invokestatic #8 // Método java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
9: areturn

Esse método tem a assinatura e expressão lambda, precisamos de um um objeto com o tipo apropriado,
semântica correta (recebe um Integer manipulador de método referencian- como veremos na próxima funciona-
e retorna um Integer). Para usar essa do-a, que será usado para construir lidade que iremos discutir.

34 InfoQ Brasil

invokedynamic
A última funcionalidade do Java 7
que abre as portas para o Java 8 é ain-
da mais esotérica que os manipulado-
res de método. Esse é o novo bytecode
invokedynamic - o primeiro bytecode
a ser adicionado à plataforma desde o
Java 1.0. Esta funcionalidade é quase
impossível de ser usada por desen-
volvedores na versão 7, porque nessa
versão o javac não irá, sob nenhuma
circunstância, gerar um arquivo class
que contenha isso.
Em vez disso, o bytecode foi pro-
jetado ser usado por desenvolvedores
de outras linguagens além do Java, tal
como JRuby, que requer muito mais
execução dinâmica que o Java. Para
ver como o invokedynamic funciona,
discutiremos como as chamadas de
método Java são compiladas em by-
tecode.
Uma chamada padrão de método
Java será convertida em um pedaço
de bytecode da JVM, que é frequen-
temente referenciado como uma cha-
mada local. Esta chamada é composta
de um código de operação de envio
(tal como invokevirtual, para chama-
das de método de instância normal)
e uma constante (um deslocamento
para o Constant Pool da classe) que
indica qual é o método a ser chamado.
Os diferentes códigos de invocação
têm regras diferentes que definem
como a pesquisa de método é feita,
mas até Java 7 sempre eram utilizadas
constantes para saber diretamente
qual o método a ser chamado.
O invokedynamic é diferente. Ao
invés de fornecer uma constante que
indica diretamente qual método deve
ser chamado, o invokedynamic forne-
ce um mecanismo de indireção que
permite o código do usuário decidir
qual método chamar em tempo de
execução.
Quando a primeira chamada com
invokedynamic é encontrada, o alvo
ainda não é conhecido. Ao invés dis-
so, um manipulador de método (cha-
mado método inicial) é invocado.
Esse método inicial retorna um objeto declaração como:
CallSite, que contém outro manipula-
dor de método, que é o alvo atual da Function<Integer, Integer> fn = x -> x + 2;
chamada do invokedynamic.
1) A chamada do invokedynamic é é convertida para uma chamada in-
encontrada no fluxo de execução (ini- vokedynamic assim:
cialmente desvinculado); 2) Chama
o método inicial e retorna um objeto Code:
CallSite; 3) O objeto CallSite tem um stack=4, locals=2, args_size=1
manipulador de método (o alvo); 4) In- 0: invokedynamic #2, 0 // InvokeDynamic
voca o método manipulador alvo. #0:apply:()Ljava/util/function/Function;
O método inicial é a maneira na 5: astore_1t
qual o código do usuário escolhe qual
método precisa ser chamado. Para ex- O método de inicialização do in-
pressões lambda, a plataforma utiliza vokedynamic é o método estático
um método de inicialização fornecido LambdaMetafactory.metafactory(),
pela biblioteca, chamado de lambda que retorna um objeto CallSite ligado
meta-factory. ao manipulador de método alvo, que
Este tem argumentos estáticos que retornará um objeto que implementa
contém um manipulador para o méto- a interface Function.
do sintetizado (veja última seção) e a Quando uma instrução invoke-
assinatura correta para o lambda. dynamic termina, um objeto que im-
O meta-factory retorna um CallSite plementa Function e que tenha uma
que contém um manipulador de mé- expressão lambda como conteúdo do
todo e que, por sua vez, retorna uma método apply() é colocado no topo da
instância do tipo correto que a expres- fila, e o resto do código pode seguir
são lambda foi convertida. Logo, uma normalmente.
Conclusão
Obter expressões lambda na plataforma Java sempre foi e vai ser uma tarefa
desafiadora, mas garantindo que o terreno adequado estava no lugar, o Java 7
facilitou consideravelmente esse esforço. O plano B não só forneceu aos desen-
volvedores o lançamento antecipado do Java 7, mas também permitiu que as
principais tecnologias realizassem testes em produção antes de usarem o Java 8
e especialmente expressões lambda.
Sobre o Autor
Ben Evans é o CEO da jClarity, uma startup que fornece ferramentas de
desempenho para auxiliar equipes de desenvolvimento e ops. Ele é um or-
ganizador no LJC (JUG Londres) e membro do comitê executivo do JCP, aju-
dando a definir padrões para os ecossistemas Java. Ele é um Java Cham-
pion; JavaOne Rockstar; coautor do “The Well-Grounded Java Developer”
e um palestrante público na plataforma Java, desempenho, concorrência
e tópicos relatados.
eMag | Java: Presente e Futuro 35
Q&A: NOVIDADES DO JAVA 8
por Matt Raible, tradução de Diogo Carleto
O Java 8 é uma das atualizações de linguagem de programação mais esperadas dos últimos anos. O novo release contém a API de datas, API de
stream e os lambdas, remove o permgen e traz um longo conjunto de melhorias. Para aprender mais sobre este lançamento, conversamos com
Georges Saab, vice-presidente de desenvolvimento de software do Java Platform Group na Oracle.
InfoQ: Para os que não têm segui-
do o projeto Lambda de perto, poderia
nos dar uma ideia do que foi envolvi-
do nesta implementação? Talvez seja
a primeira vez que tanto a linguagem
como a VM e as bibliotecas evoluíram
juntas de maneira coordenada.
A maioria das grandes funcionalidades
em versões anteriores foi feita de manei-
ra que somente uma dessas três áreas foi
afetada; ou as mudanças em cada área fo-
ram introduzidas ao longo de uma série de
grandes releases. Com o projeto Lambda
no Java 8, fizemos um mudanças coordena-
das, envolvendo a linguagem, as bibliote-
cas e a JVM. Ao longo do desenvolvimento,
cada área influenciou e fortaleceu o design
e a implementação das demais.
Experimentamos, por exemplo, com im-
plementações alternativas do Lambda na
JVM e descobrimos que poderíamos utili-
zar o InvokeDynamic. Ao fazê-lo, encontra-
mos pontos que poderiam ser melhorados
no próprio InvokeDynamic. O desejo de
utilizar Lambdas de forma natural com as
Collections nos levou ao design da Streams
API e depois aos métodos de extensão – os
quais exigiram suporte da linguagem.
Tem sido um processo evolutivo ao lon-
go de vários anos, com bastante feedback
da comunidade.
InfoQ: Você acredita que a adição
de lambdas irá trazer de volta ao Java
os desenvolvedores Groovy e Scala?
É importante lembrar que essas duas
linguagens (e muitas outras) executam na
JVM. Trabalhamos muito para suportar
outras linguagens além do Java na plata-
forma, e sinto que há muito que os imple-
mentadores de linguagens podem apren-
der com essas experiências. É claro que é
36 InfoQ Brasil
muito mais fácil experimentar com uma
linguagem com poucos milhares de desen-
volvedores que com muitos milhões. Nosso
enfoque tem sido em abordar os aspectos
que melhoram a vida dos milhões de pro-
gramadores Java, evoluindo a plataforma e
a linguagem de forma consciente e respon-
sável.
InfoQ: A combinação do Lambda
e da Streams API ajuda a desenvolver
código limpo e conciso, mas foram
levantadas preocupações quanto ao
impacto no desempenho, na medida
que filtros são aplicados seguidamen-
te para reduzir conjuntos de maneira
funcional. Quais otimizações foram
introduzidas para reduzir esse im-
pacto?
As Streams permitem operações inter-
mediárias e terminais. As operações inter-
mediárias, como filtragem, não executam
nenhuma filtragem em si; criam um novo
Stream, que quando percorrido, fornece os
elementos que correspondem a um dado
predicado.
Dessa forma, por um lado, a criação de
filtros adicionais poderia resultar em traba-
lho adicional em tempo de execução; por
outro, o processamento de streams sob
demanda, assim como as operações inter-
mediárias de streams, permite ganhos de
eficiência importantes. Isso porque várias
operações podem ser realizadas em uma
única passagem sobre os dados. E com oti-
mizações importantes da JVM nos bastido-
res possibilitado pelo design dos lambdas,
o impacto de filtros adicionais pode ser re-
duzido em boa parte.
Outro ponto a ser considerado é que a
utilização do paralelismo com Streams e
Lambdas foi simplificado. As operações de
streams em paralelo podem se beneficiar
da diminuição das restrições de ordenação,
em que os usuários não conhecem conflitos
de ordenação do stream subjacente.
InfoQ: Outra funcionalidade im-
portante do Java 8 são as Annotations
nos tipos do Java, para permitir que
verificadores de tipos “plugáveis” se-
jam desenvolvidos. Poderia nos falar
um pouco mais sobre isso?
Essa funcionalidade permite o uso de
anotações nos nomes dos tipos, na maio-
ria dos lugares onde estes tipos podem ser
usados. Como resultado da mudança, os
desenvolvedores podem agora escrever
anotações para detectar condições de erros
em tempo de compilação, usando verifica-
dores de tipos plugáveis. Esses verificado-
res e esquemas de anotações estão sendo
desenvolvidos na comunidade para erros
de null-pointer, locking e internacionaliza-
ção.
Uma boa fonte de informação e imple-
mentação é o Checker Framework do Prof.
Michael Ernst do checker-framework.org,
que inclui um checker para não-nulos, den-
tre mais de uma dúzia dessas ferramentas.
Ernst também atuou como líder da co-spec
na JSR 308, no qual esta funcionalidade da
linguagem foi especificada.
Seria ótimo ver os resultados de pelo
menos um desses esquemas de anotações
sendo aplicado sobre a base de código da
JDK no futuro; e ver a comunidade mais
ampla de desenvolvedores Java começar
a utilizar esta tecnologia em suas próprias
bases de código, além de desenvolver no-
vos verificadores para outros aspectos de
qualidade de software.
Especialmente com respeito a sistemas
embarcados e outros em que a segurança
seja crítica, esse tipo de inovação permiti-
ria que propriedades cruciais e restrições
de tipos e seu uso fossem qualificados e
analisado estatisticamente, como parte do
processo de compilação. É um caminho
para usuários de outras linguagens nesse
domínio migrarem para a plataforma Java.
InfoQ: Para linguagens dinâmi-
cas, quais são as principais melhorias
no Java 8, em sua opinião?
São as melhorias de performance na
Máquina Virtual HotSpot em geral e no
invokedynamic em particular. Outra nova
funcionalidade significativa é o engine Ja-
vaScript Nashorn. Melhorar o desempenho
do Nashorn nos ajudou a encontrar novas
oportunidades de otimização da VM para
implementações de linguagens dinâmicas.
Além disso, o Nashorn agora fornece
uma maneira conveniente de usar o Java a
partir do JavaScript, permitindo que apli-
cações JavaFX inteiras sejam escritas em
JavaScript e executadas na JVM. Essa inte-
roperabilidade transparente entre o Java e
linguagens dinâmicas executando na JVM,
oferece uma maneira poderosa de se escre-
ver aplicações web.
InfoQ: Preocupações com Java e
segurança tiveram muito destaque
nos últimos tempos. O Java 8 traz me-
lhorias nessa área, no plug-in do Java
ou em partes relacionadas?
Uma série de melhorias importantes de
segurança e novas funcionalidades foram
entregues como parte das atualizações do
Java SE 7, incluindo Deployment Rule Sets
(uma funcionalidade para empresas que
gerenciam o seu ambiente de desktop Java
diretamente) e Exception Site Lists (lista de
sites de exceção). A segurança no Java é
uma de nossas prioridades.
Além disso, o Java SE 8 contém funcio-
nalidades novas de segurança. As mais
perceptíveis são as na implementação do
Transport Layer Security: TLS 1.2. Este é
agora o padrão na plataforma. Em termos
globais de APIs de segurança, existe uma
série de outras melhorias, desde aperfei-
çoamentos na verificação de revogação de
certificados, até o uso de novos algoritmos
de criptografia.
InfoQ: Você sabe qual o percen-
tual de desenvolvedores Java usando
Java 5, 6 e 7? Existe algum plano para
acelerar a adoção do Java 8?
Ao longo dos últimos seis a nove meses,
tenho falado em conferências ao redor do
mundo e toda vez pergunto qual versão
estão usando. Apoiado sobre essa pesquisa
informal e não científica, diria que a maior
parte dos desenvolvedores Java estão
usando o Java SE 7 hoje, com minoria (sig-
nificativa) ainda usando na versão 6, e um
número pequeno em versões mais antigas.
Do ponto de vista do desenvolvedor, o
Java SE 8 tem muitas razões convincentes
para a rápida adoção, como os novos recur-
sos da linguagem e APIs. E com IDEs como
NetBeans, Eclipse e IntelliJ IDEA trabalhan-
do para oferecer suporte aos novos recur-
sos, espero ver os desenvolvedores adotar
o Java 8 rapidamente.
InfoQ: Um dos principais temas
do JavaOne 2013 foi a unificação do
Java ME, SE e EE. Até que ponto o Java
8 caminhou nessa direção?
Uma das muitas novas funcionalidades
no Java SE 8 é o suporte a Compact Profiles
(perfis compactos), que definem subcon-
juntos de perfis da plataforma Java SE. Isso
permite que aplicações que não requerem
toda a plataforma sejam publicadas e exe-
cutadas em dispositivos com menor capa-
cidade.
No mais, houve outras melhorias no
HotSpot, como a redução do tamanho de
metadados de classes e o tamanho da VM
em geral. Com isso o JDK 8 pode ser esca-
lado para o desenvolvimento de aplicativos
e a implantação em pequenos dispositivos.
E a nova ferramenta jdeps que vem com o
JDK 8 permite descobrir de qual Profile o
código sua aplicação depende.
Vindo de outra direção, o Java ME 8 está
sendo aprimorado a se alinhar mais com o
Java SE 8, quando a linguagem, VM e biblio-
tecas. Ainda não é possível utilizar lambdas
em código Java ME 8, mas a plataforma
agora suporta construções de linguagem
Java introduzidas no Java SE 1.5, 6 e 7, como
assertions, generics, enumerations, strings
em switches, declarações try-with-resour-
ces e o operador diamond.
Da mesma forma, as classes das biblio-
tecas do núcleo do Java foram atualizadas
com suporte para protocolos web moder-
nos, como IPv6 e funcionalidades avança-
das de segurança, incluindo o suporte para
TLS 1.2. Isso torna as plataformas Java SE e
Java ME mais próximas do que nunca.
InfoQ: Quando veremos a funcio-
nalidade de Stripped Implementa-
tions adicionadas ao Java? (Stripped
Implementations permitem que uma
implementação específica do Java SE
seja empacotada com a biblioteca Java
e o código da aplicação. Elementos
desnecessários são omitidos parcial-
mente ou por inteiro.)
Precisaremos voltar a examinar como a fun-
cionalidade de Stripped Implementations pode
ser adicionada à plataforma em uma versão an-
terior à 9. Não se trata de um problema técnico,
mas sim de garantir que o texto de especifica-
ção e aspectos jurídicos permitam a utilização
em vários cenários, ao mesmo tempo evitando
que haja fragmentação da plataforma Java.
eMag | Java: Presente e Futuro 37
DO GROOVY AO JAVA 8
por Dan Woods, traduzido por Daniel Sousa
Este artigo focará nas semelhanças entre o Groovy e o Java 8, e vai demonstrar o quão familiar os conceitos do Groovy se traduzem para Java 8.

D
esenvolvedores Groovy terão mais facilidade def closure = {
para adotar os conceitos e novas construções “called”
da linguagem oferecida pelo Java 8. Muitas das }
melhorias oferecidas na próxima versão do Java são assert closure instanceof java.util.concurrent.Callable
características que o Groovy oferece há anos. Desde assert closure() == “called”
uma nova sintaxe até estilos de programação funcional,
lambdas, coleção de streams, e referências de métodos Podemos fazer o Groovy implementar outras interfaces
como cidadãos de primeira classe. Os desenvolvedores funcionais por meio da conversão de tipos closures.
Groovy terão uma vantagem ao escrever o código Java no
futuro. Este artigo focará nas semelhanças entre o Groovy public interface Function {
e o Java 8, e vai demonstrar o quão familiar os conceitos def apply();
do Groovy se traduzem para Java 8. }
Começaremos discutindo estilos de programação, def closure = {
como atualmente utilizamos a programação funcional no “applied”
Groovy, e de que forma as construções em Java 8 oferecem } as Function
um estilo de programação melhor. assert closure instanceof Function
Closures são, talvez, o melhor exemplo de programação assert closure.apply() == “applied”
funcional em Groovy. Por baixo dos panos, uma closure
em Groovy é apenas a implementação de uma interface Closures e programação funcional se traduzem bem
funcional. Uma interface funcional é qualquer interface em Java 8. Interfaces funcionais são muito importantes
que possua apenas um único método para implementar. na próxima versão do Java, pois o Java 8 oferece
Por padrão, as closures do Groovy são uma implementação implementação implícita de interfaces funcionais com a
da interface funcional Callable, implementando o método introdução das funções Lambda.
“call”. As funções lambda podem ser pensadas, e utilizadas

38 InfoQ Brasil
como as closures em Groovy. Implementar uma interface return getAttribute(key);
funcional em Java 8 oferece simplicidade semelhante a }
das closures em Groovy. default Map getScope() {
return scopeMap;
Callable callable = () -> “called”; }
assert callable.call() == “called”; }
static final WebFlowScope scope =
É importante notar também que as funções lambda de (Object key) -> “edited_” + scope.getScope().get(key);
uma só linha oferecem retorno implícito, assim como no assert scope.put(“attribute”, “val”) == “val”;
Groovy.
No futuro, o Groovy também oferecerá implementação No Java 8, métodos default de interface podem também
implícita de Interfaces Funcionais para as closures, ajudar-nos a implementar características do Groovy
semelhante a oferecida pelo Java 8. Esta característica como memoization e trampoline. Memoization pode ser
da as closures a capacidade de aproveitar as variáveis implementada simplesmente criando-se uma interface
de instância e métodos sem derivar totalmente uma funcional com um método de interface default para
subclasse concreta. computar deterministicamente um resultado ou obter o
resultado do cache.
abstract class WebFlowScope {
private static final Map scopeMap = [:] public interface MemoizedFunction<T, R> {
abstract def getAttribute(def name); static final Map cache = new HashMap();
public def put(key, val) { R calc(T t);
scopeMap[key] = val public default R apply(T t) {
getAttribute(key) if (!cache.containsKey(t)) {
} cache.put(t, calc(t));
protected Map getScope() { }
scopeMap return (R)cache.get(t);
} }
} }
WebFlowScope closure = { name -> static final MemoizedFunction<Integer, Integer> fib = (Integer n) -> {
“edited_${scope[name]}” if (n == 0 || n == 1) return n;
} return fib.apply(n - 1)+fib.apply(n-2);
assert closure instanceof WebFlowScope };
assert closure.put(“attribute”, “val”) == “edited_val” assert fib.apply(20) == 6765;

Em Java 8, as Interfaces Funcionais com métodos
default na interface oferecem uma boa aproximação deste
conceito. Métodos default em interfaces são algo novo
em Java. Eles foram concebidos para permitir melhorias
nas APIs principais do Java sem violar os contratos
de implementações feitas em versões anteriores da
linguagem.
As funções lambda também terão acesso a métodos
padrão da interface em que são definidas. Isto significa
que APIs robustas podem ser construídas diretamente
em uma interface, dando recursos aos programadores
sem alterar a natureza do tipo ou do contrato no qual o
tipo pode ser utilizado.
public interface WebFlowScope {
static final Map scopeMap = new HashMap();
Object getAttribute(Object key);
default public Object put(Object key, Object val) {
scopeMap.put(key, val);
De maneira similar, podemos utilizar métodos default
de interface em Java 8 para desenvolver implementação
Trampoline. Trampoline é uma estratégia de recursão
que não sobrecarrega a pilha de chamadas do Java, e é
um recurso muito útil do Groovy quando uma recursão
profunda é necessária.
interface TrampolineFunction<T, R> {
R apply(T...obj);
public default Object trampoline(T...objs) {
Object result = apply(objs);
if (!(result instanceof TrampolineFunction)) {
return result;
} else {
return this;
}
}
}
// Encapsula a chamada do TrampolineFunction para evitar um

eMag | Java: Presente e Futuro 39

StackOverflowError
static TrampolineFunction<Integer, Object> fibTrampoline
(Integer...objs) -> {
Integer n = objs[0];
Integer a = objs.length >= 2 ? objs[1] : 0;
Integer b = objs.length >= 3 ? objs[2] : 1;
if (n == 0) return a;
else return fibTrampoline.trampoline(n-1, b, a+b);
};
Além dos recursos básicos das closures e dos recursos
mais avançados como Memoization e Trampolining,
alguns dos recursos mais práticos e úteis que o Groovy
tem para oferecer estão relacionados às extensões da
linguagem para a API Collections. Em Groovy, podemos
utilizar estas extensões para escrever atalhos e realizar
operações em listas usando o método ‘each’.
def list = [1, 2, 3, 4]
list.each { item ->
println item
} emails.add(“nemnesic@gmail.com”);
Java 8 introduz um conceito similar ao do Groovy
no que diz respeito a iterar coleções, disponibilizando o
método ‘forEach’, que substitui a maneira convencional de
percorrer listas.
List<Integer> list = new ArrayList<>();
list.add(1); list.add(2);
list.add(3); list.add(4);
list.forEach( (Integer item) -> System.out.println(item); );
Além da iteração simplificada, o Groovy dá aos
desenvolvedores uma variedade de outros atalhos
quando se trabalha com listas. O método “collect”, por
exemplo, é a abreviação para mapear elementos de uma
lista para novos tipos ou valores, coletando os resultados
em uma nova lista.
def list = [1, 2, 3, 4]
def newList = list.collect { n -> n * 5 }
assert newList == [5, 10, 15, 20]
Na implementação do Groovy, o método ‘collect’ recebe
um mapeamento como argumento, enquanto o Java 8
oferece uma implementação um pouco mais verbosa.
Usando a API Stream, os desenvolvedores podem realizar
a mesma estratégia de mapeamento e coleta chamando
o método ‘map’ no componente ‘stream’ da lista, em
seguida, chamar o método ‘collect’ a partir do stream que
é retornado na etapa de mapeamento. A API Stream dá
aos desenvolvedores a capacidade de efetuar facilmente
40 InfoQ Brasil
operações em cadeia em listas.
= List<Integer> list = new ArrayList<>();
list.add(1); list.add(2);
list.add(3); list.add(4);
List<Integer> newList =
list.stream().map((Integer n) -> n * 5).collect(Collectors.
toList());
assert newList.get(0) == 5 && newList.get(1) ==
10 && newList.get(2) == 15 && newList.get(3) == 20;
O Groovy também oferece atalhos para filtrar listas
através do método ‘findAll’.
def emails = [‘danielpwoods@gmail.com’, ‘nemnesic@gmail.com’,
‘daniel.woods@objectpartners.com’, ‘nemnesic@nemnesic.com’]
def gmails = emails.findAll { it.endsWith(‘@gmail.com’) }
assert gmails = [‘danielpwoods@gmail.com’, ‘nemnesic@gmail.com’]
De maneira semelhante, em Java 8 os desenvolvedores podem filtrar
uma lista utilizando a API Stream.
List<String> emails = new ArrayList<>();
emails.add(“danielpwoods@gmail.com”);
emails.add(“daniel.woods@objectpartners.com”);
emails.add(“nemnesic@nemnesic.com”);
List<String> gmails = emails.stream().filter( (String email) ->
email.endsWith(“@gmail.com”) ).collect(Collectors.toList());
assert gmails.get(0) == “danielpwoods@gmail.com” && gmails.get(1) ==
“nemnesic@gmail.com”;
As extensões da API Collections do Groovy tornam
fácil a ordenação de listas fornecendo à API um método
‘sort’. O método ‘sort’ também utilizará uma closure que
converte para um comparador durante a ordenação da
lista se uma lógica de ordenação especial for necessária.
Adicionalmente, se uma simples reversão da ordem da
lista é necessária, o método ‘reverse’ pode ser chamado e
a ordem invertida.
def list = [2, 3, 4, 1]
assert list.sort() == [1, 2, 3, 4]
assert list.sort { a, b -> a-b <=> b } == [1, 4, 3, 2]
assert list.reverse() == [2, 3, 4, 1]
Trabalhando novamente com a API de Stream do Java
8, podemos ordenar a lista usando o método ‘sorted’ e
obter o resultado usando o método ‘toList’ do Collectors.
O método ‘sorted’ pode receber opcionalmente uma
função de comparação como argumento (tal como uma
função Lambda), então uma lógica de ordenação especial
e reversão dos itens da lista são operações facilmente
realizadas.
List<Integer> list = new ArrayList<>();
list.add(2); list.add(3);
list.add(4); list.add(1);
list = list.stream().sorted().collect(Collectors.toList());
assert list.get(0) == 1 && list.get(3) == 4;
list = list.stream().sorted((Integer a, Integer b) ->
Integer.valueOf(a-b).compareTo(b)).collect(Collectors.toList());
assert list.get(0) == 1 && list.get(1) ==
4 && list.get(2) == 3 && list.get(3) == 2;
list = list.stream().sorted((Integer a, Integer b) -> b.compareTo(a)).
collect(Collectors.toList());
assert list.get(0) == 2 && list.get(3) == 1;
Quando usando APIs fluentes, como stream de lista,
isso pode rapidamente ser insustentável para tratar
todos os processamentos dentro de uma função closure
ou Lambda. Isso faz sentido, em alguns casos, como
delegar o processamento para um método que é adaptado
especialmente para essa unidade de trabalho.
No Groovy, podemos fazer isso passando a referência
de um método dentro da função. Uma vez que um método
é referenciado usando o operador ‘.&’, ele é convertido para
uma função closure e pode ser passado para outro método
como argumento. Intrinsecamente, isso proporciona
flexibilidade na implementação, uma vez que o código de
processamento pode ser introduzido de fontes externas.
Os desenvolvedores podem agora organizar logicamente
o processamento dos métodos obtendo uma arquitetura
de aplicação mais fácil de ser mantida e sustentável.
def modifier(String item) {
“edited_${item}”
} em grande escala no domínio da JVM por causa das
def list = [‘item1’, ‘item2’, ‘item3’]
assert list.collect(this.&modifier) == [‘edited_item1’, ‘edited_
item2’, ‘edited_item3’]
Desenvolvedores no Java 8 dispõem da mesma flexibilidade através do
uso do operador ‘::’ para obter uma referência do método.
List<String> strings = new ArrayList<>();
strings.add(“item1”);
strings.add(“item2”);
Daniel Woods é consultor sênior na Object Partners, Inc. Ele é especialista
em Arquitetura de Aplicações com Groovy e Grails, mantendo forte interes-
se em Java e outras linguagens baseadas na JVM.
strings.add(“item3”);
strings = strings.stream().map(Helpers::modifier).collect(Collectors.
toList());
assert “edited_item1”.equals(strings.get(0));
assert “edited_item2”.equals(strings.get(1));
assert “edited_item3”.equals(strings.get(2));
Os métodos de referência podem ser passados como
argumentos para qualquer método que necessita de uma
interface funcional. Por sua vez, os métodos de referência
terão a forma de interfaces funcionais e podem ser
tratadas como tal.
public interface MyFunctionalInterface {
boolean apply();
}
void caller(MyFunctionalInterface functionalInterface) {
assert functionalInterface.apply();
}
boolean myTrueMethod() {
return true;
}
caller(Streaming::myTrueMethod);
No Java 8, os desenvolvedores de bibliotecas podem
fazer mudanças nos contratos das interfaces sem que os
consumidores tenham que atualizar a forma de interagir
com as bibliotecas.
A tradução perfeita dos conceitos e estilos de
programação do Groovy para o Java 8 é uma ponte
importante entre duas linguagens. O Groovy foi adotado
flexibilidades de herança e melhorias nas APIs existentes
do Java. Com muitas dessas melhorias enraizando no
Java 8, isso significa que a similaridade entre as duas
linguagens estão começando a superar as diferenças, um
fato que este artigo pretende delinear. Para finalizar, os
desenvolvedores que possuem experiência em Groovy
terão uma curva de aprendizado pequena para aprender
e adaptar as novas APIs, funcionalidades e conceitos
Sobre o Autor
Daniel pode ser contatado através do email
danielpwoods@gmail.com ou pelo Twitter
@danveloper.
eMag | Java: Presente e Futuro 41
NASHORN: COMBINANDO O PODER DO JAVA E
JAVASCRIPT NO JDK 8
por Oliver Zeigermann, traduzido por Rafael Sakurai
No JDK 8, o Nashorn substituiu o Rhino como motor padrão de JavaScript do Java por oferecer melhorias de desempenho e compatibilidade.
O Avatar.js trouxe o popular modelo de programação do Node para o Nashorn, permitindo que muitos servidores de aplicações JavaScript possam ser
executados no ambiente Java.
D
esde o JDK 6, o Java foi liberado contendo um
motor de JavaScript com base no Rhino da
Mozilla. Essa funcionalidade permite embarcar
código JavaScript dentro do Java e até chamar no Java o
código JavaScript embarcado. Além disso, ele permite
a execução de JavaScript através de linha de comando
usando o jrunscript. Isso é bom o suficiente quando
não há necessidade de muito desempenho e é possível
conviver com um conjunto limitado das funcionalidades
do ECMAScript 3.
Começando com o Nashorn do JDK 8 atualizando o
Rhino como motor embarcado de JavaScript no Java. O
Nashorn fornece suporte completo para a especificação
do ECMAScript 5.1 com mais algumas extensões. Permite
compilar o JavaScript em bytecode Java usando as novas
funcionalidades da linguagem com base na JSR 292,
incluindo o invokedynamic, que foi introduzido no JDK 7.
42 InfoQ Brasil
Isso fornece um desempenho de 2 a 10x a mais
que a antiga implementação do Rhino, apesar de ter o
desempenho um pouco inferior ao V8, o motor dentro
do Chrome e Node.js. Se estiver interessado nos detalhes
da implementação dê uma olhada nesses slides do JVM
Language Summit de 2013.
Como o Nashorn vem com o JDK 8, ele dá suporte às
interfaces funcionais, como veremos em mais detalhes
adiante.
Vamos começar com um exemplo bem simples. Primeiro
será necessário instalar o JDK 8 e o NetBeans, IntelliJ IDEA
ou Eclipse. Essas IDEs fornecem ao menos o suporte básico
de JavaScript integrado com o desenvolvimento. Vamos
criar um simples projeto Java contendo dois arquivos de
exemplo e em seguida executaremos o programa, como
mostrado na figura a seguir:
 Na linha 12 usamos o método “eval” para avaliar
qualquer código JavaScript. Nesse caso apenas
carregamos o arquivo JavaScript principal e o
avaliamos. Não se preocupe com o “print” no código,
ele pode não parecer familiar porque não construímos
essa função no JavaScript, mas o Nashorn fornece
essa e outras funções por conveniência, que são
convenientes no ambiente de scripting. Também seria
possível passar o comando de impressão do “hello
world” direto como argumento para o “eval”, mas
ter o JavaScript em seu próprio arquivo abre todo um
mundo de ferramental para ele.
Atualmente o Eclipse não possui um suporte
dedicado para o Nashorn através do projeto da
Ferramenta de Desenvolvimento de JavaScript (JSDT),
no entanto suporta o ferramental básico e a edição de
JavaScript.
eMag | Java: Presente e Futuro 43
 O IntelliJ IDEA 13.1 (edição da comunidade e final)
fornece excelente suporte ao JavaScript e Nashorn. Há
funcionalidades completas para depurar e também
permitir o refatoramento que sincroniza o Java com o
JavaScript; então por exemplo, se renomear uma classe
Java que é referenciada no JavaScript ou se renomear
um arquivo JavaScript que é usado no Java, a IDE
Pode-se dizer que o ferramental é bom e que a nova
implementação corrige os problemas de desempenho
bem como o problema de estar em conformidade com
o JavaScript, mas por que devemos usa-lo? Uma razão
pode ser o script em geral. Algumas vezes pode ser útil
para tratar alguns tipos de strings e deixar apenas que
seja interpretada. Algumas vezes pode ser bom não
ter um compilador no caminho ou não se preocupar
com tipos estáticos, ou talvez o interesse no modelo de
programação do Node.js, que pode ser usado no Java
como veremos no final desse artigo. Há também o caso
do desenvolvimento no JavaFX que será muito mais
rápido usando JavaScript do que apenas Java.
O motor do Nashorn pode ser executado através da
Shell scripts
linha de comando usando o comando jjs. Pode executa-
44 InfoQ Brasil
modificará as referências correspondentes entre as
linguagens.
A seguir temos um exemplo que permite depurar
uma chamada ao JavaScript através do Java (note que
o NetBeans também fornece depuração de JavaScript
como mostrado na figura a seguir):
lo sem argumentos para abrir o modo interativo, ou
pode informar o nome do arquivo JavaScript que
deseja executar, ou pode usar para substituir o shell
script, exemplo:
#!/usr/bin/env jjs
var name = $ARG[0];
print(name ? “Hello, ${name}!” : “Hello, world!”);
Para passar argumentos no programa através do
jjs, utilize o prefixo “--”. Dessa forma podemos ter
uma chamada como a seguinte:
./hello-script.js -- Joe
Sem o prefixo “--”, o parâmetro será interpretado
como o nome do arquivo.
 Passando dados para o Java e vice-versa
Como mencionado anteriormente, é possível
chamar o JavaScript direto do código Java através
do motor chamado “ScriptEngine” e chamando seu
método “eval”. É possível passar dados explicitamente
como strings ...
ScriptEngineManager scriptEngineManager
= new ScriptEngineManager();
ScriptEngine nashorn = scriptEngineManager.
getEngineByName(“nashorn”);
String name = “Olli”;
nashorn.eval(“print(\’” + name + “\’)”);
… ou pode passar referências do Java que podem
ser acessadas como variáveis globais dentro do motor
de JavaScript:
int valueIn = 10;
SimpleBindings simpleBindings = new SimpleBindings();
simpleBindings.put(“globalValue”, valueIn);
nashorn.eval(“print (globalValue)”, simpleBindings);
O resultado da execução do JavaScript é devolvido
através do método “eval” do motor:
Integer result = (Integer) nashorn.eval(“1 + 2”);
assert(result == 3);
Usando classes Java no Nashorn
Como mencionado anteriormente, uma das
funcionalidades mais poderosas do Nashorn é o uso de
classes do Java dentro do JavaScript. É possível tanto
acessar as classes e criar instâncias como também
criar subclasses delas, chamar membros estáticos
e fazer virtualmente qualquer coisa que é possível
diretamente no Java.
Como um exemplo, vamos dar uma olhada em
threads. O JavaScript não tem nenhuma funcionalidade
da linguagem para tratar concorrência e todos os
ambientes de execução comuns são de processos
únicos ou pelo menos sem qualquer compartilhamento
de estado. É interessante ver que no ambiente do
Nashorn o JavaScript pode de fato ser executado
concorrentemente e com compartilhamento de estado,
tal como no Java:
// é assim que obtemos acesso à classe Thread do Java.
var Thread = Java.type(“java.lang.Thread”);
// cria a subclasse com o método run.
var MyThread = Java.extend(Thread, {
run: function() {
print(“Run in separate thread”);
}
});
var th = new MyThread();
th.start();
th.join();
Note que a maneira canônica de acessar uma classe
através do Nashorn é usando o Java.type e estendendo
uma classe através do Java.exend.
Linguagem funcional
Por todos os aspectos, com o lançamento do JDK
8, o Java tornou-se - pelo menos até certo ponto - uma
linguagem funcional. Agora é possível usar funções
de ordem superior nas coleções, por exemplo para
iterar sobre um conjunto de elementos. Uma função
de ordem superior é uma função que tem outra função
como parâmetro e faz algo significativo com ela. Veja
um exemplo em Java:
List<Integer> list = Arrays.asList(3, 4, 1, 2);
list.forEach(new Consumer() {
@Override
public void accept(Object o) {
System.out.println(o);
}
});
Nesse exemplo, ao invés de iterar sobre os
elementos usando um laço “externo” como fazemos
tradicionalmente, agora passamos uma função
“Consumer” para o método “forEach”, uma operação
de ordem superior realiza um “laço interno” e executa
o método “accept” do Consumer, percorrendo cada
elemento da coleção, um a um.
Como mencionado, a abordagem da linguagem
funcional para tal função de ordem superior aceitaria
um parâmetro de função, em vez de um objeto. A
passagem como referências para as funções em si, não é
algo tradicional fornecido no Java, o JDK 8 agora possui
alguns tipos sintáticos para expressar justamente o
uso de expressões lambda (também conhecidas como
“closures”). Por exemplo:
List<Integer> list = Arrays.asList(3, 4, 1, 2);
list.forEach(el -> System.out.println(el));
Nesse caso o parâmetro para o “forEach” tem o
formato de uma referência de função. Isso é possível
porque o Consumer é uma interface funcional (algumas
vezes chamado de tipo de Método Abstrato Simples, ou
do inglês “Single Abstract Method - SAM”).
eMag | Java: Presente e Futuro 45
 Então, porque abordamos lambdas na discussão
sobre Nashorn? Porque no JavaScript podemos
escrever códigos como esse e o Nashorn está
especialmente preparado para fazer a ligação entre o
Java e o JavaScript nesse caso. Em particular, porque
permite passar funções escritas em JavaScript como
implentações de interfaces funcionais (tipo SAM).
Vejamos alguns simples exemplos de código
JavaScript que fazem coisas iguais as feitas com
código Java. Note que não há uma forma de
construção de listas no JavaScript, apenas arrays; mas
esses arrays são dimensionados dinamicamente e
tem métodos para comparação deles com uma lista
em Java. Então, nesse exemplo estamos chamando o
método “forEach” de um array em JavaScript:
var jsArray = [4,1,3,2];
jsArray.forEach(function(el) { print(el) } );
A similaridade é óbvia; mas isso não é tudo.
Podemos também converter um array em JavaScript
para uma lista em Java:
var list = java.util.Arrays.asList(jsArray);
Esse código JavaScript executa dentro do Nashorn.
Como isso agora é uma lista do Java, podemos
chamar o método “forEach”. Note que esse não é o
mesmo método “forEach” que chamamos no array
em JavaScript, mas sim o método “forEach” definido
nas collections. Ainda, podemos passar uma função
simples em JavaScript:
list.forEach(function(el) { print(el) } );
O Nashorn permite que passemos funções em
JavaScript como referência, nos locais que esperam
interfaces funcionais (tipo SAM). Portanto, isso não
é possível apenas no Java, mas também no JavaScript.
A próxima versão do ECMAScript - que espera-
se a versão final para esse ano - incluirá uma sintaxe
curta para funções que permitirá códigos similares
aos lambdas em Java, exceto que no JavaScript será
usado seta dupla =>. Isso facilitará ainda mais o
alinhamento entre as linguagens.
Dialeto especial do JavaScript no Nashorn
O Nashorn suporta atualmente a versão 5.1
do ECMAScript e mais algumas extensões. Não
recomendo o uso dessas extensões porque não se
parecem com Java e nem JavaScript, parece algo não
natural para os desenvolvedores. No entanto há duas
46 InfoQ Brasil
extensões que são usadas na documentação da Oracle
e podemos nos familiar com elas.
Primeiro vamos configurar o cenário para a
primeira extensão. Como visto anteriormente
podemos estender classes Java através do JavaScript
usando o Java.extend. Se quiser criar uma subclasse de
uma classe Java abstrata ou implementar um interface
podemos usar uma sintaxe mais conveniente. Nesse
caso é possível chamar virtualmente o construtor
de uma classe abstrata ou interface e passar um
objeto literal JavaScript que descreve os métodos
implementados. As literais do objeto JavaScript são
apenas pares de nome e valor, muito parecido com
o formato JSON. Nesse exemplo foi implementado a
interface Runnable:
var r = new java.lang.Runnable({
run: function() {
print(“running...\n”);
}
});
Nesse exemplo estamos virtualmente chamando
o construtor de Runnable com um objeto literal que
especifica a implementação do método run. Note que,
isso é algo que a implementação do Nashorn possui,
em outros casos isso não seria possível apenas com
JavaScript.
O código desse exemplo é bem parecido com a
implementação de uma interface usando uma classe
interna anônima em Java. Isso nos leva a primeira
extensão, que deixa passar o último parâmetro após o
parênteses “)” de fechamento durante a chamada do
construtor. Fazendo isso, o código ficaria como esse ...
var r = new java.lang.Runnable() {
run: function() {
print(“running...\n”);
}
};
… que faz exatamente a mesma coisa, mas tem
uma semelhança ainda maior com o Java.
A segunda extensão mais usada é um atalho
para as funções que permite omitir ambas as chaves
bem como a instrução de retorno, para que o corpo
do método possa ser em uma única linha. Assim, o
exemplo da sessão anterior ...
list.forEach(function(el) { print(el) } );
… pode ser expresso de forma ligeiramente mais conciso:
list.forEach(function(el) print(el));
Avatar.js
Vimos que com o Nashorn temos um bom motor
de JavaScript embarcado no Java. Também vimos que
o Nashorn pode acessar as classes do Java. O Avatar.js
vai um passo além e traz “o modelo de programação
do Node, APIs e os módulos do ecossistema para a
plataforma Java”. Para entender o que isso significa
e porque é excitante, primeiro vamos entender o que
é o Node.
O Node é basicamente uma extração do motor de
JavaScript V8 do Chrome que pode ser executado
através de linhas de comando, sem precisar de
um navegador. Isso permite que o JavaScript seja
executado não apenas no navegador, mas também no
lado servidor. Para executar o JavaScript no servidor
de uma forma significativa, será necessário acessar
pelo menos o sistema de arquivos e a rede. Para fazer
isso, o Node possui uma biblioteca chamada libuv
que faz isso de maneira assíncrona. Na prática, isso
significa que as chamadas ao sistema operacional não
ficam bloqueadas mesmo que demorem algum tempo
para responder. Ao invés de bloquear, é fornecida
uma função de callback que será acionada uma vez
que a chamada terminar, entregando os resultados,
se houver algum.
Há diversas empresas que usam o Node para
aplicações sérias, como o Walmart e o Paypal.
Vejamos um pequeno exemplo de JavaScript que
foi adaptado do site do Node:
// carrega o módulo ‘http’ (isso é bloqueante)
para tratar requisições http.
var http = require(‘http’);
// quando há uma requisição, retornamos ‘Hello, World\n’.
function handleRequest(req, res) {
res.writeHead(200, {‘Content-Type’: ‘text/plain’});
res.end(‘Hello, World\n’);
} limitações; o number do JavaScript, como o double
// Vamos escutar a porta 1337 do localhost
// e dar um handleRequest quando a chamada voltar.
// Veja aqui a forma sem bloqueio / assíncrona.
http.createServer(handleRequest).listen(1337, ‘127.0.0.1’);
// registramos no console para garantir
que a aplicação foi inicializada.
console.log(‘Get your hello at http://127.0.0.1:1337/’);
Para executar esse código será necessário instalar
o Node, salvar o códigos JavaScript no arquivo e
finalmente chamar o Node passando o arquivo como
parâmetro.
O objetivo do Avatar.js é fornecer a mesma
API central como o Node ligando o libuv com as
classes Java e então torná-lo acessível ao JavaScript.
Mesmo que isso possa parecer complicado, funciona
surpreendemente bem. O Avatar.js suporta diversos
módulos Node e suporta o “express” - o principal
framework web para Node - indicando que isso pode
funcionar com diversos projetos existentes.
O Avatar.js possui uma distribuição binária que
pode ser encontrada no site do projeto bem como os
passos para a sua instalação.
Um vez que tenha configurado os binários e
colocados na pasta lib, podemos então chamar o
framework Avatar.js usando algo como:
java -Djava.library.path=lib -jar lib/
avatar-js.jar helloWorld.js
Assumimos que no servidor de demonstração está
salvo um arquivo chamado “helloWorld.js”.
Novamente perguntamos, porque isso é útil? As
pessoas na Oracle (slide 10) viram diversos casos de
uso para uma biblioteca. Concordo principalmente
com dois deles:
1. Se temos uma aplicação Node e queremos usar
certas bibliotecas do Java para complementar a API
do Node;
2. Se queremos trocar para as APIs do JavaScript e
Node, mas precisamos embarcar o código Java legado
em partes ou completamente.
Ambos casos de uso funcionam usando o Avatar.
js e chamando qualquer classe necessária do Java
através do código JavaScript, que é suportado pelo
Nashorn.
Vejamos um exemplo do primeiro uso. O JavaScript
tem atualmente apenas um único tipo para expressar
números chamado “number”. Sendo equivalente ao
tipo de precisão do “double” do Java, com as mesmas
do Java não é capaz de expressar tamanho e precisão
arbitrária, por exemplo para tratar de valores
monetários.
No Java podemos usar o BigDecimal, que suporta
exatamente isso. Mas o JavaScript não tem uma
construção equivalente, então podemos acessar a
classe BigDecimal através do código JavaScript e ter
o mesmo tratamento seguro de valores monetários.
Vejamos um exemplo de web service que calcula o
percentual de alguma quantia. Primeiro precisamos
de uma função que faz o cálculo real:
eMag | Java: Presente e Futuro 47
 var BigDecimal = Java.type(‘java.math.BigDecimal’);
function calculatePercentage(amount, percentage) {
var result = new BigDecimal(amount).multiply(
new BigDecimal(percentage)).divide(
new BigDecimal(“100”), 2,
BigDecimal.ROUND_HALF_EVEN);
return result.toPlainString();
} Outro caso de uso relacionado, podemos ter uma
No JavaScript não há declaração de tipos, mas fora
isso, o código se parece muito com o código Java,
como mostrado a seguir:
public static String calculate(String
amount, String percentage) {
BigDecimal result = new BigDecimal(amount).multiply(
new BigDecimal(percentage)).divide(
new BigDecimal(“100”), 2,
BigDecimal.ROUND_HALF_EVEN);
return result.toPlainString();
}
Apenas precisamos substituir a função handleRe-
quest do Node, como no exemplo anterior, para com-
pletarmos o código. Como esse:
// Carrega o módulo utilitário ‘url’ para converter a url.
var url = require(‘url’);
function handleRequest(req, res) {
// ‘/calculate’ é o caminho do web service.
if (url.parse(req.url).pathname === ‘/calculate’) {
var query = url.parse(req.url, true).query;
// Quantia e percentual são passados como
parâmentro de consulta da requisição.
var result = calculatePercentage(query.amount,
query.percentage);
res.writeHead(200, {‘Content-Type’: ‘text/plain’});
res.end(result + ‘\n’);
}
}
Usamos o segundo módulo principal do Node
para processar a URL da requisição para converter os
parâmetros da consulta em quantia e porcentagem.
Após iniciar o servidor, se fizermos uma requisi-
ção como ...
http://localhost:1337/calculate?amoun-
t=99700000000000000086958613&percentage=7.59
48 InfoQ Brasil
… usando o navegador web, obtemos a resposta
correta “7567230000000000006600158.73” que seria
impossível de calcular usando apenas o tipo “num-
ber” do JavaScript.
O segundo caso pode fazer mais sentido quando
decidimos migrar uma aplicação JEE existente para
JavaScript e Node. Nesse caso podemos facilmente
acessar todos os serviços existentes com o JavaScript.
nova parte da funcionalidade do servidor construído
usando JavaScript e Node que pode se beneficiar dos
serviços JEE existentes.
Indo na mesma direção, há também o Projeto Ava-
tar que é baseado no Avatar.js. Os detalhes vão além
do escopo desse artigo, mas para ter uma visão rápida
dê uma olhada no anúncio feito pela Oracle. A ideia
básica é escrever a aplicação em JavaScript e acessar
os serviços JEE. O Projeto Avatar vem com uma dis-
tribuição binária combinanda com o Avatar.js mas
precisa do Glassfish para instalar e desenvolver.
O projeto Nashorn aumentou a implementação
original do Rhino no JDK 6 fornecendo melhorias
de desempenho para aplicações de execução longa,
por exemplo quando usamos dentro de um servidor
de aplicações web. O Nashorn integra o Java com
o JavaScript e permite usar as novas expressões
lambdas do JDK 8. Uma inovação real vem com o
Avatar.js que fornece integração com o Java EE e o
código JavaScript sendo amplamente compatível com
o padrão para programação no servidor JavaScript.
Os exemplos completos, incluindo o binário do
Avatar.js para Mac OS X, estão disponíveis no Github.
Sobre o Autor
Oliver Zeigermann é consultor de arquitetura e desen-
volvimento de software, e Coach em Hamburg, Alema-
nha. Atualmente tem se concentrado em usar JavaS-
cript em aplicações corporativas.
JAVA 9 E ALÉM: BRIAN GOETZ E JOHN ROSE
FALAM SOBRE O FUTURO DO JAVA
O InfoQ convidou Brian Goetz (arquiteto da linguagem Java) e John Rose (arquiteto da JVM) para discutir a funcionalidades previstas
para o Java 9 e versões posteriores.
InfoQ: Vocês distinguem entre a reificação de tipos
genéricos e a especialização primitiva. Podem falar mais
sobre isso?
Goetz: Os desenvolvedores não se sentem bem com a remoção
de informações de tipos (type erasure); têm o sentimento de estar
fazendo alguma coisa errada. Na verdade, o type erasure é útil e
aplicar a técnica gera poucos problemas. Por outro lado, o Boxing é
ineficiente, usa mais memória, enfraquece a localidade e demanda
mais do Garbage Collector. É ótimo que código como ArrayList<T>
possa abstrair diversos Ts. Mas o desenvolvedor não deve pagar o
preço do boxing para obter a abstração dos tipos genéricos – quan-
do tudo o que precisa é de um Array de tipos inteiros primitivos.
InfoQ.com: E quanto às formas de type erasure em in-
terfaces, com perda de informação, como em sobrecargas?
List<String> e List<Map<String, Integer>> seriam tipos
distintos no Java 10?
Goetz: List<String> e List<Integer> sempre foram tipos diferen-
tes, mas esses dois tipos são representados pela mesma classe em
tempo de execução. A remoção de informação de tipos (erasure)
impede que se descubra se um tipo List foi definido como List<S-
tring> ou um List<Integer> antes de a informação ser removida.
Uma tradução heterogênea completa de tipos genéricos, como
a usada nos templates do C++, mapearia cada um desses tipos para
uma classe separada, sem relação entre essas classes. Não é o que
estamos propondo. Mas alguns tipos genéricos como List<int> po-
dem ser representados por uma classe diferente de List<String>.
Ou seja, o mapeamento de tipos em tempo de compilação para
classes em tempo de execução pode funcionar de forma diferente,
na criação de listas para tipos primitivos e em listas para referência
de objetos.
Rose: Isso significa que as estruturas equivalentes de tipos de
valor que tiveram informação de tipos removida aparecerão no
bytecode.
Goetz: Dizendo de outra maneira: desenvolvedores que estão
usando (raw types) ou <?> para evitar fazer certas decisões, terão
de aprender como fazer corretamente. Assim que tivermos espe-
cialização e valores de tipo (value types), o uso de raw types será
cada vez menos aceito. Se você não sabe usar bem tipos genéricos,
chegou a hora de aprender. Já estamos percebemos coisa do gê-
nero com os lambdas. Se você consultar o Stack Overflow, vai ver
muitas perguntas do tipo: “por que não consigo fazer isso e aquilo
com um lambda?”. São questões relacionadas ao uso incorreto de
tipos genéricos, o que faz o sistema de inferência de tipos falhar.
InfoQ.com: Falem um pouco sobre a possibilidade de
Optional ser um tipo “proto-value”
Goetz: Havia uma pequena otimização potencial ao migrar um
tipo de referência do Java 8 para um tipo de valor no Java 10. Ba-
eMag | Java: Presente e Futuro 49
sicamente, preparamos o terreno indicando aos desenvolvedores
que não devem depender que certas propriedades (como verifica-
ção de identidade) sejam verdadeiras para os tipos que podem se
tornar value types no futuro. Sempre que a migração para tipos de
valor se mostrar útil na prática, ela poderá acontecer.
InfoQ.com: Haverá JSRs para os projetos Panama e o
Valhalla, ou para alguma tecnologia vinda deles? Quando
saberemos em qual release do Java serão incluídos?
Rose: É sempre melhor iniciar uma JSR quando já se tem ideia
de onde se quer chegar. A criação de JSRs deve acontecer ideal-
mente entre dois momentos: depois de determinar a versão do JDK
e antes de se ter um protótipo bem aceito.
Goetz: Exatamente. Isso é similar com o que aconteceu com os
lambdas, que iniciamos juntamente com o OpenJDK. A JSR foi lan-
çada assim que definimos os critérios de sucesso para o projeto os
especialistas que formariam o Expert Group da JSR.
Rose: As JSRs trazem muitos benefícios, mas é necessário um
bom ponto de partida – especialmente para não acontecer de for-
marmos uma equipe cedo depois e desperdiçar o tempo dos es-
pecialistas.
Goetz: Temos sorte que agora todos os aspectos legais para
desenvolver as JSRs no OpenJDK estão resolvidos. Assim podemos
desenvolvê-las de forma aberta desde o início. Com relação a re-
leases, acompanhe os repositórios do Valhalla, especialmente as
pequenas migrações entre os repositórios do JDK9 e JDK 10.
InfoQ.com: O que dizem sobre os projetos com novas
abordagens para acesso a dados, como os Packed Objects
da IBM e o ObjectLayout de Gil Tene?
Sobre os Participantes
50 InfoQ Brasil
Rose: O Java tem 20 anos de idade e ouvem-se reclamações so-
bre arrays desde a primeira versão. Estamos convergindo para uma
API que permita atingir dados unidimensionais (flat data). Estamos
chegando perto de iniciar protótipos – que é o objetivo do Projeto
Panama. A IBM foi envolvida desde o início; há uma lista de discus-
são especial de que os engenheiros da VM da empresa podem par-
ticipar. São necessárias mudanças na linguagem, por exemplo os
value types e mudanças em algumas premissas.
InfoQ.com: A Hazelcast, entre outras empresas, tem
pedido por arrays usando índices do tipo long. Isso é pos-
sível?
Rose: Todas as novas APIs para dados em que estamos traba-
lhando têm índices long.
Goetz: Estamos trabalhando nisso, mas temos que lembrar que
com relação a novas funcionalidades há um número muito grande
de combinações possíveis: em esparsidade, tamanho, leitura e es-
crita ou somente leitura. Os desenvolvedores têm diferentes neces-
sidades e é necessário priorizar.
Rose: É verdade. Há muitos graus de liberdade, como em pi-
zzas! Não queremos tratar uma “pizza de cogumelos e cebolas”
como uma combinação completamente diferente de uma “pizza
com cebolas e pimentas”. Isso nos levaria a uma explosão combi-
natória. Queremos, em vez disso, que se possa dizer “escolha várias
coberturas”. Ainda estamos trabalhando para definir o “cardápio”
a ser oferecido
Um padrão de arquitetura comum é separar os dados gerencia-
dos pela aplicação. Usuários têm custos incrementais de gerencia-
mento, portanto vão querer gerenciar os dados eles mesmos. Isso
leva a um número grande de bytes formatados pela aplicação, o
que leva diretamente ao acesso nativo a dados.
Brian Goetz é desenvolvedor profissional há mais
de 20 anos e autor do popular livro ‘Java Concur-
rency in Practice’. Escreveu mais de 75 artigos sobre
desenvolvimento em Java e foi líder da especifica-
ção que trouxe os lambdas para a linguagem (JSR
335). Goetz é o Arquiteto da Linguage Java na Ora-
cle.
John Rose é líder do projeto Da Vinci no OpenJDK.
Liderou a JSR 292, que introduziu no Java o suporte
a invocações dinâmicas e profiling de tipos. Antes
disso, participou da criação dos inner cla
NOVOS HORIZONTES DO JAVA
por Ben Evans, Victor Grazi e Abraham Marín Pérez.
Tradução/Adaptação: Leonardo Galvão, Wellington Pinheiro e Wellington Soares
A renovação da linguagem e plataforma Java está acelerando. Com muitas novas características no horizonte para versão 9 e além, o Java continua
avançando em qualidade, desempenho e facilidade de uso. Conheça nesse artigo uma seleção do que está por vir.

S
Se havia dúvidas que o Java era o padrão de fato para
desenvolvimento no lado servidor, o Java 8 resolveu
essa questão. Agora o mundo aguarda ansiosamente
pelo Java 9, atualmente agendado para março de 2017.
Há muitas coisas no horizonte para versão 9 e além. O
projeto Jigsaw pode ser considerado o carro-chefe do Java
9; está destinado a trazer programação modular ao mains-
tream do Java. Depois de anos de negociações e múltiplas
JSRs e JEPs, o projeto está assumindo sua forma final.
Outras novas funcionalidades do Java 9 são o suporte
a HTTP/2 e o REPL, além de um modelo de memória re-
novado e novas técnicas de garbage collection. O HTTP/2
trata de problema antigos do suporte enferrujado ao
HTTP no Java atual.
Já o REPL é permite a desenvolvedores testar códigos
interativamente, sem a necessidade de se preocupar com
estruturas de classes e compiladores. E o novo coletor de
lixo Garbage First (também conhecido como G1GC) pro-
mete suportar heaps imensos com o mínimo de interrup-
ções.
A inovações, porém, vão bem além dessa lista. Nas
seções seguintes compilamos um pequeno histórico da
Primeiros anúncios
evolução do Java 9, adaptando várias notícias e artigos do
InfoQ, Conheça o que está a caminho!
O Java 9 teve início em agosto de 2014, quandi a Oracle
anunciou o primeiro grupo de JEPs para o Java 9 (JEP
= Java Enhancement Proposal – ‘Proposta de Aperfeiço-
amento’).
Os JEPs fazem parte de um novo processo que permite
funcionalidades da linguagem e VM do Java para ser ex-
ploradas sem a necessidade de um processo de especifica-
ção completo como o atual JSR. Isso permite que o escopo
dos JEPs seja menor e mais focado e que tratem são especí-
ficos à implementação OpenJDK. JEPs bem sucedidas po-
dem então ser convertidas em pedidos de padronização
no JSR ou incluídas em padrões existentes.
Três novas APIs foram anunciadas inicialmente:
• Process API Updates para interação com processos
de sistema operacional não baseados em Java;
• Um novo HTTP Client que inclui suporte a HTTP/2;
• Uma nova API leve para JSON, que deve ser cons-
truída com base no suporte a JSON (JSR 353).
• Há também três novidades voltadas ao desempenho:

eMag | Java: Presente e Futuro 51

 • Melhoria em locks de contenção, para aumento de
desempenho quando múltiplos threads competem
pelo acesso a objetos;
• Segmentação do cache de código do JIT, para me-
lhor desempenho do compilador Just in Time em
grandes aplicações;
• Novas melhorias no compilador Java “inteligente”, o
sjavac; essa ferramenta promete compilação parale-
la e compartilhada, entre outras melhorias.
Quanto ao JEP 201 (Código Fonte Modular), ele não era
neste momento o o projeto Jigsaw prometido para versões
anteriores do Java – mas sim um trabalho de limpeza no
OpenJDK preparando as bases para a modularidade.
Esse JEP estabeleceu limites claros para cada módulo
ao mesmo tempo que o próprio JDK está sendo construído.
Outras novidades
Foi um primeiro passo na direção da modularidade com-
pleta, ainda que os módulos não estivessem visíveis ao
desenvolvedor em tempo de execução.
Em novembro de 2014, a Oracle anunciou outras fun-
cionalidades do Java 9, com destaque para a modularida-
de da plataforma. Veja outras mudanças anunciadas:
• Logging unificado na JVM – uma grande revisão
no mecanismo interno de notificação de eventos na
JVM, permitindo substituir o atual sistema de log-
ging por um sistema comum e unificado, possibi-
litando que diversos componentes compartilhem o
mecanismo de logging;
• Remoção de combinações de GC obsoletas – a re-
moção das combinações: DefNew + CMS, ParNew
+ SerialOld e Incremental CMS. Estas haviam sido
marcadas como obsoletas no Java 8;
• Mais controle sobre o compilador – melhoria no
controle sobre o compilador Hotspot JIT, permitin-
do adicionar opções para cada método a ser compi-
lado e alterar as opcões em runtime. Por exemplo,
adicionar diretivas para habilitar ou desabilitar
uma otimização específica para determinado méto-
do, remover a opção de o método ser inline ou até
mesmo instalar uma diretiva durante a execução e
verificar seu resultado;
• Project Coin atualizado – Ajustes em alguns deta-
lhes originados no Java 7 (Project Coin) que trouxe
mudanças na linguagem. Serão permitidos @Safe-
Vargs em métodos privados, o operador diamond
com inner classes, entre outras mudanças.
Novidades incluem também o término do projeto
de remoção de warnings e uma limpeza no gerenciador
de importação. Ao importar classes obsoletas, não serão
mais disparados alertas. Além disso, alguns problemas
antigos na resolução de tipos no javac serão corrigidos.
O suporte a algumas tecnologias modernas também
52 InfoQ Brasil
foi anunciado, incluindo o Datagram Transport Layer Se-
curity (DTLS), e uma atualização da ferramenta Javadoc
para geração de HTML5.
As JEPs também indicam que a especialização de tipos
primitivos em tipos genéricos (para permitir estruturas
como List<int>) não está mais planejada para o JDK9, mas
sim para o JDK10.
Data final quase definida, com alguns sacrifícios
Em julho de 2016, Mark Reinhold, Arquiteto Chefe da
Plataforma Java, sugeriu um método para avaliar coleti-
vamente o trabalho restante em JEPs inacabadas, e decidir
se será atrasado o Java 9 ainda mais para acomodar as úl-
tima mudanças – ou se serão retirados JEPs pendentes do
escopo da versão 9. O processo está em andamento, mas
tudo indica que deve haver uma combinação dessas duas
estratégias.
Por um lado, há uma conjunto fundamental de fun-
cionalidades que dão sentido à nova versão. Para esses,
a data final tem de ser adiada, a fim de incluir as funcio-
nalidades centrais. Por outro lado, Reinhold enfatiza a
importância de se estabelecer um ritmo previsível para
novas versões. Ele percebe que funcionalidades não-fun-
damentais devem ser removidas do escopo se não forem
terminadas a tempo.
Esse raciocínio está alinhado com o processo proposto
para seleção de JEPs. Desse modo, espera-se que os líderes
das JEPs solicitem uma prorrogação do prazo, indicando a
data estimada de entrega – ou comuniquem a sua “saída”
do Java 9. No caso de prorrogação, um processo de revisão
irá determinar se a extensão será concedida ou não.
Atualmente 11 JEPs estão em análise – de um total de
82.
Entre os JEPs em risco de saírem do Java 9, a julgar pelo
estado do issue tracker no momento de escrita, dez soli-
citaram prorrogação do prazo (com sete já aprovados). A
data de entrega revista para estas JEPs é 1 de setembro,
o que significa atraso de cerca de três meses – levando o
lançamento do Java 9 para junho de 2017.
Quatro JEPs seriam removidos do release para evitar
novos atrasos:
• JEP 110 Cliente HTTP / 2
• JEP 227 Depreciação melhorada
• JEP 282 JLINK
• JEP 284 Novo sistema de builds do HotSpot
Embora ainda não haja definição final, as decisões re-
centes tendem a estabelecer a forma definitiva do Java 9.
Porém, se os JEPs acima forem mesmo removidos, uma
análise mais aprofundada será necessária para ava-
liar seu impacto, especialmente com relação ao JEP 282
(JLINK), que faz parte do sistema de módulos, central à
nova versão do Java.
eMag | Java: Presente e Futuro 53