Java tem sido o sonho de um programador e qual é a melhor maneira de quantificar a popularidade de Java com a nova versão Java 13. Após a proposta inicial de aprimoramento de Java, houve avanços nos recursos do JDK que explodiram a mente do desenvolvedor de Java com uma nova variedade de recursos. após o lançamento oficial em 17 de setembro de 2019.
Mas por que você acha que o Java é tão popular?Java tem sido uma mania entre os programadores devido à sua independência de plataforma e à capacidade de rodar em computadores diferentes. Está presente há tanto tempo que foi adotado por organizações como bancos, seguradoras, empresas, agências e principalmente por
empresas de terceirização de software .
O Java está presente no mercado para desenvolver aplicativos Android, aplicativos Web Java, ferramentas de software e aplicativos científicos.
Vamos nos aprofundar nas estatísticas e avaliar a taxa de popularidade dos aplicativos Java entre outras linguagens de programação concorrentes.
De acordo com o recente relatório de setembro do
Tiobe Index , aplicativos e programadores Java têm se apegado a sua posição e têm enfrentado dificuldades para outras linguagens de programação.
Depois de ver a tribo de popularidade do Java entre outras linguagens de programação, passemos para os recursos do Java 13 JDK rapidamente:
- JEP 350: Arquivos CDS dinâmicos
- JEP 351: ZGC: Confirmação de memória não utilizada
- JEP 353: Reimplementar a API do Soquete Legado
- JEP 354: Expressões de Switch (Visualização)
- JEP 355: Blocos de Texto (Visualização)
Como não podemos esperar muitas mudanças após o lançamento inicial do Java 12, ainda há mudanças em um nível funcional que pode passar os programadores de Java para novos recursos estáveis. O objetivo é finalizar os recursos de visualização até a próxima versão do LTS, para que sejam estáveis o suficiente e tenham uma boa aparência nos próximos três anos. Esperava-se que, em setembro de 2021, o Java 17 assumisse o legado do Java 8 e 11.
Neste blog, mostrarei os recursos mais recentes que você pode esperar do Java 13.-> Arquivos CDS dinâmicosAlém dos novos recursos que são óbvios para os
desenvolvedores de Java , muita coisa aconteceu sob o teto da JVM e das bibliotecas da classe. O CDS (Class Data Sharing) foi introduzido novamente durante o Java 5. O objetivo final do CDS é reduzir os horários de início dos aplicativos Java, armazenando certas informações sobre as classes nos arquivos do Class Data Sharing. Os dados podem ser carregados no tempo de execução e usados por várias JVMs.
Até o Java 10, no entanto, os arquivos compartilhados eram acessíveis apenas para o Bootstrap ClassLoader. A partir do Java 10, o CDS foi estendido pelo Application Class Data Sharing (AppCDS). O AppCDS permite que o carregador de classes do sistema e da plataforma integrados, bem como os carregadores de classes definidos pelo usuário, acessem os arquivos do CDS. As listas de classes são necessárias para criar os arquivos do CDS, a fim de identificar as classes a serem carregadas.
Anteriormente, essas listas de classes tinham que ser determinadas por execuções de teste do aplicativo para determinar quais classes foram realmente carregadas durante a execução. Desde o Java 12, os arquivos CDS padrão são entregues com o JDK por padrão, com base na lista de classes do JDK.
Os arquivos CDS dinâmicos agora se baseiam nisso. O objetivo é salvar as execuções de teste adicionais do aplicativo. Após a execução de um aplicativo, apenas o aplicativo recém-carregado e as classes da biblioteca que ainda não estão contidas no CDS da Camada Padrão / Base são arquivados. O arquivamento dinâmico é ativado com comandos da linha de comando. Em uma extensão futura, o arquivamento de classes poderá ser executado de forma totalmente automática e transparente.
-> ZGC: Confirmar memória não utilizadaAtualmente, não é tão incomum que os aplicativos tenham que atender milhares de usuários ao mesmo tempo. Esses aplicativos precisam de muita memória e o gerenciamento da memória é significativo, o que afeta o desempenho do aplicativo. Para atender aos requisitos declarados, a Oracle introduziu o Z Garbage Collector (
ZGC ) no Java 11, pois promete pausas muito curtas ao limpar as memórias de pilha com vários terabytes.
Anteriormente, não liberava a memória heap liberada reservada para aplicativos. Como resultado, os aplicativos consomem muito mais memória do que o necessário. Um aplicativo que é executado em ambientes com poucos recursos é particularmente afetado. Outros coletores de lixo, como o G1 e o Shenandoah, já oferecem suporte à liberação de memória não utilizada.
-> APIs de soquete renovadasO Java Socket e o Java ServerSocketAPIs são fragmentos do JDK 1.0. A maioria deles consiste em legado de Java e C Code. Isso dificulta muito a manutenção e a extensibilidade. O NioSocketImpl deve substituir o PlainSocketImpl desatualizado agora. O NioSocketImpl já se baseia na implementação de Nova E / S existente e usa sua infraestrutura existente no JDK.
A implementação anterior não é compatível com outras extensões planejadas do idioma. Por exemplo, problemas de simultaneidade impedem o uso futuro dos encadeamentos de usuário leves (fibra, parte do tear do projeto).
-> Aprimoramentos para expressões de switchSe você observar o recurso do ponto de vista do desenvolvedor, esse é o ponto que é meramente interessante. Por exemplo, o Switch Expressions foi introduzido como uma visualização no Java 12 e foi estendido devido ao feedback do usuário. As expressões de switch são uma alternativa para as instruções de switch complicadas e propensas a erros.
A maior mudança nas normas de codificação que pode ser vista no Java 13 é a substituição da quebra de palavra-chave na expressão do comutador pelo rendimento. O fundo é a melhor diferenciação entre uma instrução switch (com possível interrupção) e expressões (com rendimento). A declaração de rendimento sai da opção e retorna o resultado da ramificação atual, semelhante a um retorno.
Por exemplo, o trecho de código abaixo mostra o cenário em que a instrução do Switch foi usada com quebra e, na outra parte, a Expressão do Switch foi usada com o rendimento para fazer a diferença entre os dois.
-> Blocos de texto em vez de literais de seqüência de caracteres brutabloco de texto é um novo tipo para definir a string literal na linguagem Java. Pode ser usado para indicar uma string em qualquer lugar em que uma literal de string possa ser usada, mas oferece maior expressividade e menos complexidade acidental. A primeira implementação do Raw String Literals levantou muitas questões, pois os usuários deram feedback sobre o mesmo que possui várias perguntas múltiplas.
Afinal, muitos aplicativos Java podem processar trechos de código de outros idiomas, como HTML ou SQL. Até agora, essas cadeias só podiam ser definidas de uma maneira complicada, o que as torna difíceis de ler.
Por exemplo, comandos de controle extras (escapando com \ n) devem ser usados para quebras de linha. Outros idiomas, como Groovy, Scala ou
Kotlin, há muito oferecem a possibilidade de definir textos de várias linhas.
O novo bloco de texto usa aspas triplas como delimitadores e pode ser usado sempre que cadeias normais são permitidas.
O trecho de código abaixo explica a diferença entre os dois:
As aspas triplas de abertura e fechamento devem estar em uma linha separada. No entanto, o conteúdo real começa com a segunda linha. Isso aumenta a legibilidade do código fonte, pois o recuo da primeira linha é exibido corretamente no texto fonte.
Conclusão:As mudanças descritas até agora foram definidas nos JEPs (Java Enhancement Protocols). No entanto, existem outras adaptações diretamente na biblioteca de classes. Mas primeiro, você precisa instalar o Java 13 enquanto a versão do Java 14 ainda está em andamento.
As alterações são incertas e alguns recursos, como Expressões de Switch e Bloco de Texto, podem ser finalizados. No entanto, o próximo lançamento está a caminho.