0

Java 17 - O que eles estão construindo - e por quê?

#Java
Edson Gallo
Edson Gallo

Como projetos Java, como Loom, Panama e Valhalla estão lançando a base para o futuro da plataforma


Quatro maiores arquitetos Java - Mark Reinhold, arquiteto-chefe do Java Platform Group; Brian Goetz, arquiteto-chefe de linguagem Java; Mikael Vidstedt, diretor de engenharia de software da Java Virtual Machine; e Ron Pressler, membro consultor da equipe técnica Java - respondem seis perguntas sobre a vibração do Java, as prioridades do grupo e o futuro da plataforma.

Aqui está o que eles têm a dizer.


O que mantém o Java vibrante?

“Sempre fomos guiados por um conjunto claro de valores”, diz Reinhold, “e levamos a noção de administração muito a sério”.

“Não adicionamos coisas ao Java com base no que é legal este ano”, acrescenta, ou porque a linguagem x ou a linguagem y têm uma função específica. “Tomamos muito cuidado quando adicionamos coisas à plataforma, quando fazemos alterações e quando ocasionalmente, raramente, removemos coisas.”


Mark Reinhold, arquiteto-chefe do Java Platform Group
Mark Reinhold, arquiteto-chefe, Grupo de plataforma Java


Para Reinhold, a linguagem e a plataforma Java enfatizam o código legível. “A legibilidade é um valor fundamental. O outro valor-chave, eu diria, é a compatibilidade. Levamos a compatibilidade a sério, embora ocasionalmente removamos coisas, como fizemos recentemente. ”

Não muito foi removido, Reinhold acrescenta: “Existem muitos, muitos arquivos JAR empoeirados por aí, criados em Java 1.0, Java 1.2 e Java 1.4, que funcionam muito bem hoje. Isso não é algo que você pode dizer sobre outras plataformas. ”

Outro grande fator para a longevidade do idioma tem sido o ecossistema, a comunidade como um todo, destaca Reinhold. “Conseguimos manter uma atmosfera de apoio e coleguismo. Além disso, temos todos os grupos de usuários e conferências em todo o mundo, com foco em Java e tecnologias relacionadas. ”

Com o passar dos anos, as razões para a popularidade do Java podem ter mudado, observa Pressler. “Hoje em dia, Java é reconhecido como uma plataforma séria, para software sério. A plataforma é confiável e oferece uma combinação incomparável de desempenho, produtividade e capacidade de observação - com o que quero dizer monitoramento e criação de perfil. ”

“A administração e os valores que trazemos para a evolução da plataforma Java são aumentados com uma mistura incomum de teoria e prática”, diz Goetz. “Onde a plataforma atende ao modelo de programação, que é o que a maioria dos desenvolvedores vê todos os dias, nós nos concentramos em evoluir a plataforma, para que ela permaneça relevante para os problemas que as pessoas desejam resolver.”

Goetz continua: “Ao mesmo tempo, na sala de máquinas, a especificação e implementação da VM, o JIT [compilador just-in-time], o coletor de lixo, a especificação da linguagem - tomamos muito cuidado com evolução dessas tecnologias. E, como resultado, podemos continuar a evoluir a especificação e implementação 25 anos depois. ”


Brian Goetz, arquiteto-chefe de linguagem, Java

Brian Goetz, arquiteto-chefe de linguagem, Java


Vidstedt aponta para a estabilidade: “A plataforma Java tem uma interface realmente estável. A superfície está muito bem definida, o que significa que, novamente, aqueles arquivos JAR empoeirados da década de 1990 ainda rodam em sua maioria. Isso é complexo, e a complexidade pode ser desafiadora, como um implementador, para trabalhar. Podemos gastar esse tempo resolvendo esses problemas complexos, para que os usuários e desenvolvedores não tenham realmente que se preocupar tanto com isso. ”

“A interface estável e bem definida deixa muito espaço para inovação abaixo da superfície”, acrescenta Vidstedt. “A tecnologia JVM é uma tecnologia legal. Existem muitas áreas desafiadoras diferentes e temos uma comunidade realmente saudável em torno disso. Muitas pessoas estão investindo em Java, desde empresas até a academia - e os desenvolvedores nos ajudam a descobrir o que fazer a seguir. ”


Como a equipe Java prioriza quais recursos da linguagem Java implementar?

“A questão sugere que nossa metodologia deve começar com uma lista grande, enorme e longa de recursos, e nós simplesmente priorizamos tudo nela”, ri Reinhold, dizendo que não é assim que o Java Platform Group funciona. “O que estamos sempre perguntando é: 'Devemos fazer dentro do núcleo da plataforma com a linguagem, a JVM, as bibliotecas, o que não pode ser feito fora da plataforma?'”

Reinhold explica que o aprendizado de máquina é uma área importante e isso levou a várias sugestões, como implementar o formato de ponto flutuante bfloat16 ou uma API TensorFlow . “Todas são sugestões bem-intencionadas - mas implementá-las seria a coisa errada. Qualquer pessoa deve ser capaz de criar uma API TensorFlow e definir um novo tipo de ponto flutuante. Mas hoje isso não é possível. ”

É por isso que, diz Reinhold, a ênfase do Java Platform Group está em tornar o Java mais extensível. “Por exemplo, em vez de adicionar bfloat16 ao nosso pequeno estábulo de tipos primitivos infelizes, estamos trabalhando no Projeto Valhalla para possibilitar que qualquer pessoa defina seus próprios tipos primitivos efetivamente novos.”

“O princípio de fazer, na plataforma, o que absolutamente não pode ser feito fora dela, é um bom guia”, acrescenta Reinhold. “É isso que procuramos constantemente.”

Bibliotecas são fundamentais, diz Goetz. “Quando estamos projetando recursos de linguagem, perguntamos: 'Como os recursos de linguagem permitem que as pessoas escrevam bibliotecas mais poderosas?' As mudanças na biblioteca são muito melhores do que as mudanças no idioma. As mudanças de linguagem demoram muito e afetam a todos. No entanto, se pudermos permitir que o ecossistema resolva nas bibliotecas o problema que os desenvolvedores desejam resolver e competir por quem tem a melhor biblioteca TensorFlow ou biblioteca de análise JSON, então todos ganham. ”


Os programadores Java devem desistir dos configuradores e modelar seus objetos de domínio de forma imutável, ou apenas com registros, daqui em diante?

“O ou / ou que está implícito na pergunta, sugerindo que há apenas uma maneira certa de modelar dados em seu programa, é um pouco enganoso”, diz Goetz. “Nosso colega Alex Buckley, líder de especificações para a linguagem Java e JVM, gosta de dizer que uma das coisas surpreendentes é que o Java conseguiu errar em todos os padrões e ainda assim teve sucesso.”


Mikael Vidstedt, Diretor Sênior de Desenvolvimento de Software, Java

Mikael Vidstedt, diretor de software para a máquina virtual Java


É por isso que, diz Goetz, em Java, o padrão para mutabilidade está errado. O padrão para acessibilidade está errado. O padrão para saber se uma classe é extensível está errado. “No entanto, de alguma forma, conseguimos sobreviver a esses erros.”

“A convenção de nomenclatura JavaBeans é um pouco infeliz”, continua ele. “É uma convenção terrível para desenvolvimento de propósito geral. Era uma convenção bastante bem direcionada para nomear componentes visuais em um editor visual, onde você arrastava e soltava botões e rótulos e coisas assim em uma tela, e você tinha folhas de propriedades que você poderia editar sobre a cor de primeiro plano e fontes e o que você tem, o que poderia ser descoberto reflexivamente. ”

Goetz explica que a convenção de nomenclatura foi uma ótima maneira de construir esses componentes de IU - o que acabou por não ser um caso de uso chave do Java. “E, no entanto, de alguma forma, continuamos com essa convenção de nomenclatura, embora seja uma correspondência tão ruim para a maioria dos objetos de domínio de negócios.”

“Por causa dessas convenções, a mutabilidade é superutilizada e superestimada”, diz Goetz. “A imutabilidade é uma ferramenta para gerenciar a complexidade, porque nos permite focar nossa atenção nas partes do projeto que realmente precisam ser complexas.”

A resposta é registros. “Registros são um recurso de linguagem que reconhece a importância da imutabilidade”, diz Goetz. “Os registros tornam mais fácil modelar dados como dados e, juntos, os tipos selados e a correspondência de padrões estão movendo o Java em direção a um modelo de programação orientado a dados.”

Goetz continua: “Os programas estão ficando menores, à medida que usamos mais serviços, microsserviços e funções como um serviço menores. Mais código está mais perto do limite e os desenvolvedores terão que lidar com dados que chegam não como um objeto Java, mas como alguma string desamarrada de XML ou JSON ou qualquer outra coisa. Queremos modelar esses dados como dados comuns. A linguagem Java está se movendo em uma direção que torna mais fácil fazer isso. ”


O que você diria aos desenvolvedores que estão presos ao Java 8 ou versões anteriores, para fazê-los mergulhar na piscina e aproveitar as versões atuais do Java?


Ron Pressler, membro de consultoria, equipe técnica Java

Ron Pressler, membro de consultoria, equipe técnica Java


“Esses desenvolvedores provavelmente estão perdendo uma quantia significativa de dinheiro que o uso de um JDK moderno poderia salvá-los”, diz Pressler. “Melhorias na área de cobertura da memória, como strings compactas; melhorias no desempenho, como melhores otimizações do compilador e inicialização mais rápida; melhorias na área de cobertura e no desempenho, devido a mudanças massivas no coletor de lixo G1 e a introdução do ZGC , um coletor de lixo que fornece pausas de um ou dois milissegundos; bem como melhorias no Oracle Java Flight Recorder, que podem ajudar a otimizar o código do aplicativo. Tudo isso se traduz em significativamente menos hardware necessário para atender à mesma carga de trabalho. Em muitos, se não na maioria dos casos, acho que a economia na hospedagem de hardware compensaria os custos de migração muito rapidamente. ”

Além disso, Pressler acrescenta: “Para começar, quem quer estar abaixo da linha de base de segurança? Você realmente deseja colocar seu aplicativo ou sua empresa em risco usando software antigo? É chocante, às vezes, quando você se depara com a frequência com que essa situação é, porque as organizações não sabiam. Então, agora você sabe. ”


Com o Project Loom, vale a pena manter a programação reativa? Se sim, por quê?

“A programação reativa surgiu para permitir que os servidores utilizem melhor seu hardware para um melhor rendimento”, diz Pressler. “Essa foi uma das melhores respostas para o problema de servidores de alto rendimento que poderíamos fazer sem mudar o JDK. E, em alguns casos, para requisitos de aplicação como esse, a programação reativa era a única escolha. ”

Dito isso, Pressler admite, apesar de necessária em muitas situações, a programação reativa choca-se com o design da plataforma Java. “Você perde as informações de solução de problemas contidas nas exceções. Você perde os perfis de desempenho do Oracle Java Flight Recorder e a interface do depurador. Essas ferramentas pressupõem que o contexto de uma transação de aplicativo lógico está vinculado ao estado de um thread. ”

Infelizmente, acrescenta Pressler, essa suposição está profundamente enraizada na JVM, nas ferramentas e na linguagem Java. “E a programação reativa meio que quebra tudo.”

“Quando um alto rendimento é necessário, a programação reativa pode ser a melhor escolha e, em alguns casos, você não tem escolha”, ressalta Pressler. “No entanto, o Project Loom tenta resolver o mesmo problema, de forma harmoniosa com o design da plataforma Java e suas ferramentas. Além disso, o Loom torna a integração com o código legado mais fácil. ”

Como o Project Loom muda a própria plataforma Java, nos bastidores, os programadores podem continuar a usar suas APIs familiares. “Meu palpite é que, quando o Loom chegar, muitos desenvolvedores preferirão obter melhor rendimento usando threads virtuais”, prevê Pressler. “Claro, todos que preferem o estilo reativo são livres para mantê-lo. Também é possível que as bibliotecas reativas possam até encontrar maneiras de usar threads virtuais para reduzir a incompatibilidade entre o estilo de programação reativo e a plataforma Java. ”


Quais são algumas das próximas grandes coisas que os desenvolvedores Java devem saber?

Reinhold diz que após os lançamentos do Projeto Valhalla e do Projeto Panamá , ele está ansioso para digitar aulas. “Também seria bom voltar a algumas das ideias que Ron [Pressler] estava explorando no início do Loom, particularmente em torno de chamadas finais e continuações . As continuações, em particular, são um recurso extremamente poderoso. ”

“Não está claro para mim se algum dia desejaríamos expor chamadas finais e continuações na plataforma para uso geral”, acrescenta Reinhold, “mas pode haver maneiras de usá-las dentro da plataforma, de algumas maneiras bastante interessantes”.

Goetz aponta que os desenvolvedores precisam reconhecer que projetos como Valhalla não são projetos unitários. “Não é como se Valhalla fosse fazer uma entrega, e então ela estava pronta. Existem várias coisas saindo de cada um desses projetos - e cada um deles permitirá coisas mais interessantes no futuro. ”

Por exemplo, Goetz diz, você poderia pensar sobre Valhalla de duas maneiras diferentes. “Você pode pensar no Valhalla como tipos de dados mais planos e densos, o que é em grande parte uma visão voltada para o desempenho de olhar para ele, e isso é verdade. Você também pode considerar o Valhalla como unificando o sistema de tipos, de forma que tipos e objetos primitivos sejam unificados em um modelo sensato. Isso afeta a forma como desenvolvemos o código. ”

“Todo mundo teve a experiência desagradável de ter que especializar manualmente algum código, onde você escreveu uma implementação genérica de algo, mas agora você tem que fazer uma versão especial para intarrays ou longarrays ou o que quer que seja”, acrescenta Goetz. “Este tipo de ondulação de complexidade pode afetar particularmente as bibliotecas. Ao unificar o sistema de tipos, permitiremos que bibliotecas muito mais interessantes sejam escritas. ”

Goetz ri: “Nunca ficaremos sem o que fazer. Sempre haverá coisas fora do alcance do que somos capazes de fazer. Dito isso, projetos como o Valhalla são um bom exemplo de nos dar mais com o que trabalhar e nos dar novos recursos, enquanto deixa as coisas com uma superfície mais lisa para construir no futuro. ”

“Vou encerrar dizendo que não sei qual será a próxima grande novidade, mas posso ter esperança”, diz Pressler. “Estou ansioso para trabalhar na otimização de chamadas finais. Algo que poderia ser modernizado é a experiência gestáltica de usar as várias ferramentas. A experiência do desenvolvedor é algo que espero que possamos melhorar em um futuro próximo. ”


Artigo original escrito por Alan Zeichick para a Java Magazine (https://blogs.oracle.com/javamagazine/java-architects-loom-panama-valhalla), mostra o que as principais mentes brilhantes por trás da evolução do Java estão fazendo. Interessante saber que o Java está se modernizando continuamente e que está contemplando Machine Learning nesta evolução.

0
1

Comentários (0)

Tecnólogo em PD pela Universidade Presbiteriana Mackenzie, com Especialização em Gestão de Projetos pela USP.

Brasil