Mostrando postagens com marcador Programação. Mostrar todas as postagens
Mostrando postagens com marcador Programação. Mostrar todas as postagens

terça-feira, 27 de janeiro de 2026

📝 Mapeamento para String com MapStruct: Convertendo Enums, Datas e Objetos em Java

1. Visão Geral

Ao trabalhar com aplicações Java, muitas vezes precisamos converter objetos de dados complexos em representações mais simples. Por exemplo, é comum converter tipos de dados como enums, números ou objetos aninhados para seus equivalentes em String para exibição, registro em log (logging) ou respostas de API. Nesse cenário, podemos usar o MapStruct.

Neste tutorial, vamos mapear diferentes tipos de dados para uma String.


2. Configuração do Projeto

Para demonstrar o mapeamento para String no MapStruct, podemos criar um projeto Maven simples mapstructstringmapping.

No arquivo pom.xml, vamos navegar até o diretório mapstructstringmapping e atualizar:

<dependencies>
    <!-- MapStruct -->
    <dependency>
        <groupId>org.mapstruct</groupId>
        <artifactId>mapstruct</artifactId>
        <version>1.6.3</version>
    </dependency>

    <!-- JUnit 5 -->
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.14.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Acima, adicionamos mapstruct para mapeamento em tempo de compilação e JUnit 5 para testes.


3. Mapeamento Simples para String

Ao trabalhar em apresentações ou mesmo em respostas de API, podemos precisar converter valores numéricos ou booleanos em strings. Um bom exemplo é quando uma entidade de banco de dados armazena a idade de um usuário como um int, mas a camada de API precisa expô-la como uma String.

Vamos examinar um exemplo direto para mostrar como usar o MapStruct para mapear um campo int para uma String. Primeiro, definimos a classe Person:

public class Person {
    private String name;
    private int age;
}

Em seguida, vamos criar a segunda classe PersonDTO:

public class PersonDTO {
    private String name;
    private String age;
}

Nos exemplos acima, as classes possuem getters e setters padrão, que o MapStruct utilizará para o mapeamento.

Agora, vamos definir a interface do mapper PersonMapper.java:

@Mapper
public interface PersonMapper {

    PersonMapper INSTANCE = Mappers.getMapper(PersonMapper.class);
    PersonDTO toDTO(Person person);
}

Em tempo de compilação, o MapStruct cria a implementação de PersonMapper. Neste caso, o MapStruct automaticamente altera o valor int de age do objeto de origem para uma String no objeto de destino quando o método toDTO() é chamado.

Vamos criar o teste unitário PersonMapperUnitTest.java e garantir que o mapeamento funciona como pretendido:

public class PersonMapperUnitTest {

    @Test
    void givenPerson_whenMapsToPersonDTO_thenFieldsAreCorrect() {

        Person person = new Person();
        person.setName("Alice");
        person.setAge(30);

        PersonDTO dto = PersonMapper.INSTANCE.toDTO(person);

        assertEquals("Alice", dto.getName());
        assertEquals("30", dto.getAge());
    }
}

O teste confirma que o valor int da idade é traduzido para sua representação em String e que o campo name é mapeado com sucesso.


4. Conversão de Enums para String

Em Java, enums são amplamente usados para definir conjuntos fixos de variáveis, incluindo funções de usuário, status de pedidos e estados do sistema. No entanto, quando os dados são mostrados em interfaces do usuário ou tornados acessíveis através de APIs, esses valores de enum geralmente são renderizados como strings.

4.1. Definindo o Enum e as Classes de Domínio

Vamos começar definindo um enum que representa o status de um usuário:

public enum Status {
    ACTIVE,
    INACTIVE,
    PENDING
}

Para seguir em frente, vamos criar um objeto de domínio que usa este enum:

public class User {
    private String username;
    private Status status;
}

Por fim, criamos um DTO onde o valor do enum é representado como uma String:

public class UserDTO {
    private String username;
    private String status;
}

Agora, a classe User usa um enum para o campo status, enquanto UserDTO espera o mesmo valor como uma String.

4.2. Definindo o Mapper

Vamos definir uma interface de mapper que converte um User em um UserDTO:

@Mapper
public interface UserMapper {

    UserMapper INSTANCE = Mappers.getMapper(UserMapper.class);

    UserDTO toDto(User user);
}

Aqui, o MapStruct detecta automaticamente que o campo de origem é um enum e o campo de destino é uma String. Não precisamos definir nenhuma lógica de mapeamento personalizada. Ele invoca o método name() do enum durante o processo de mapeamento.

Na maioria das APIs do mundo real, esse comportamento padrão é suficiente, mas é importante estar ciente disso se os nomes dos enums não corresponderem aos valores esperados pelos clientes.

4.3. Verificando o Mapeamento

Vamos escrever um teste unitário que confirma que a conversão de enum para string funciona conforme o esperado:

public class UserMapperUnitTest {

    @Test
    void shouldMapEnumToString() {

        User user = new User();
        user.setUsername("Kevin");
        user.setStatus(Status.ACTIVE);

        UserDTO dto = UserMapper.INSTANCE.toDto(user);

        assertEquals("Kevin", dto.getUsername());
        assertEquals("ACTIVE", dto.getStatus());
    }
}

Isto é o que o teste verifica:

  • O campo username é mapeado corretamente
  • O valor do enum Status.ACTIVE é convertido para sua representação em String, “ACTIVE”

Notavelmente, este comportamento funciona "pronto para uso" com MapStruct e não requer configuração adicional.


5. Mapeando Datas para String

Ao trabalhar com campos de data, muitas vezes precisamos convertê-los em representações de string formatadas antes de expô-los através de APIs ou exibi-los em interfaces do usuário. O MapStruct suporta este caso de uso através do atributo dateFormat na anotação @Mapping.

Usando este atributo, podemos definir o padrão de data exato que queremos que o MapStruct aplique durante o processo de mapeamento.

5.1. Definindo as Classes de Domínio e DTO

Vamos começar definindo uma entidade de domínio simples que contém um campo LocalDate:

public class Event {
    private String name;
    private LocalDate eventDate;
}

Em seguida, vamos definir um DTO correspondente onde o campo eventDate é representado como uma String:

public class EventDTO {
    private String name;
    private String eventDate;
}

Aqui, a classe Event representa o modelo de domínio, enquanto EventDTO é o objeto de transferência de dados usado para saída. A diferença principal é que o campo eventDate é um LocalDate no objeto de origem e uma String formatada no objeto de destino.

5.2. Criando o Mapper

Agora, vamos definir uma interface de mapper para converter um Event em um EventDTO:

@Mapper
public interface EventMapper {

    EventMapper INSTANCE = Mappers.getMapper(EventMapper.class);

    @Mapping(source = "eventDate", target = "eventDate", dateFormat = "yyyy-MM-dd")
    EventDTO toEventDTO(Event event);
}

Aqui, @Mapping especifica que o campo eventDate deve ser formatado de acordo com o padrão "yyyy-MM-dd" (por exemplo, "2024-12-31"). O MapStruct cuida da conversão do objeto LocalDate para a representação de string correspondente.

5.3. Testando a Conversão de Data

Para garantir que o mapeamento e a formatação funcionam corretamente, podemos escrever um teste unitário:

public class EventMapperUnitTest {

    @Test
    void shouldMapLocalDateToStringUsingProvidedFormat() {

        Event event = new Event();
        event.setName("Conferência");
        event.setEventDate(LocalDate.of(2024, 12, 31));

        EventDTO dto = EventMapper.INSTANCE.toEventDTO(event);

        assertEquals("Conferência", dto.getName());
        assertEquals("2024-12-31", dto.getEventDate());
    }
}

O teste acima confirma que:

  • O campo name é mapeado sem alterações
  • O objeto LocalDate é formatado corretamente no padrão especificado "yyyy-MM-dd"

O uso do atributo dateFormat é particularmente útil para garantir a consistência dos formatos de data em diferentes pontos de extremidade da API ou componentes da interface do usuário.


6. Considerações Adicionais e Melhores Práticas

Lidando com Valores Nulos

Em cenários do mundo real, os dados de origem podem conter valores nulos. O MapStruct lida com eles de forma segura por padrão, mas é importante testar e documentar o comportamento esperado em seus mapeadores.

Customizando Conversões Complexas

Para cenários mais complexos (por exemplo, formatar números com casas decimais específicas, converter objetos aninhados em strings JSON), você pode usar métodos default dentro da interface do mapper ou definir um método de mapeamento personalizado usando a anotação @Named.

Testes Abrangentes

Sempre escreva testes para seus mapeadores, cobrindo casos de uso comuns, casos de borda (valores nulos, enums desconhecidos) e formatos específicos. Isso garante que as conversões de dados permaneçam confiáveis conforme sua aplicação evolui.


7. Conclusão

Neste tutorial, exploramos como usar o MapStruct para mapear vários tipos de dados para suas representações em String. Vimos como o mapeamento direto de tipos primitivos como int funciona automaticamente, como converter valores de enum usando o método name() e como formatar objetos LocalDate usando o atributo dateFormat na anotação @Mapping.

💡 O MapStruct simplifica significativamente a conversão de dados em aplicações Java, fornecendo mapeamento seguro de tipos em tempo de compilação. Ao utilizar esses padrões, podemos manter nosso código limpo, legível e fácil de manter ao lidar com diferentes representações de dados em nossas aplicações.

quinta-feira, 22 de janeiro de 2026

🔍 Visualizando o Código-Fonte de um Arquivo .class do Java: Como Descompilar Bytecode

🔍 Visualizando o Código-Fonte de um Arquivo .class do Java

No mundo Java, o código-fonte escrito em arquivos .java é compilado para um formato intermediário chamado bytecode, armazenado em arquivos com extensão .class. Esses arquivos não contêm o código-fonte original legível, mas instruções para a Java Virtual Machine (JVM). Então, como podemos "visualizar" o código original a partir de um arquivo .class? A resposta está na descompilação – processo de reconstruir o código-fonte a partir do bytecode.


🧠 O Que é Bytecode e Por Que Precisamos Descompilar?

O bytecode é uma representação compacta e otimizada do seu programa, projetada para ser executada pela JVM. Ele não é destinado à leitura humana. No entanto, situações como análise de bibliotecas de terceiros, debugging de problemas complexos, estudos de código legado sem fonte disponível ou até recuperação de código perdido podem exigir que você visualize algo próximo ao código original. É importante ressaltar que a descompilação para fins de engenharia reversa deve respeitar os termos de licença do software e os direitos autorais.


🛠️ Ferramentas Populares para Descompilar Arquivos .class

Existem várias ferramentas robustas que convertem bytecode Java em código legível. Aqui estão as principais:

1. JD-GUI

Uma ferramenta gráfica gratuita que permite abrir arquivos .class ou .jar e navegar pela estrutura descompilada como se fosse um projeto. Ela fornece uma visualização limpa e imediata, sendo excelente para análises rápidas.

2. Bytecode Viewer

Uma ferramenta mais avançada que mostra não apenas o código descompilado (usando motores como CFR, FernFlower ou Procyon), mas também o bytecode real e o código em hexa. É ideal para desenvolvedores que querem entender a relação entre o código-fonte e as instruções da JVM.

3. CFR

É um descompilador moderno e de alta qualidade, disponível como biblioteca ou via linha de comando. Ele lida bem com recursos mais novos da linguagem, como lambdas e switch expressions, gerando um código reconstruído muito fiel.


📝 Passo a Passo Prático com JD-GUI

  1. Baixe e execute o JD-GUI a partir do site oficial.
  2. Abra seu arquivo .class ou .jar através do menu "File > Open File...".
  3. Navegue pela árvore do projeto no lado esquerdo. Ao clicar em uma classe, o código descompilado aparecerá no painel principal.
  4. Exporte o código se necessário, usando "File > Save All Sources".

⚠️ Limitações e Considerações Importantes

A descompilação não é uma mágica perfeita. Nomes de variáveis locais são perdidos, sendo substituídos por nomes genéricos (var1, var2). Comentários e formatação original são completamente removidos. Estruturas como laços for-each podem aparecer como iteradores tradicionais. Além disso, código ofuscado propositalmente pode gerar uma saída ilegível. Do ponto de vista legal, usar código descompilado para criar uma obra derivada sem permissão viola licenças de software.


🔧 Visualizando Bytecode Puro (javap)

Às vezes, você não quer o código reconstruído, mas sim inspecionar as instruções reais do bytecode. Para isso, use a ferramenta javap, que vem com o JDK. Execute no terminal: javap -c -p NomeDaClasse.class. A flag -c exibe as instruções bytecode e -p mostra membros privados. É uma análise de baixo nível valiosa para otimização ou debugging profundo.


🎯 Conclusão

Descompilar arquivos .class é uma habilidade útil no arsenal de qualquer desenvolvedor Java, seja para aprender, solucionar problemas ou analisar dependências. Ferramentas como JD-GUI e Bytecode Viewer tornam o processo acessível. No entanto, use esse conhecimento com responsabilidade ética e legal, sempre respeitando a propriedade intelectual. Lembre-se: a descompilação é uma ferramenta de análise, não de cópia. Dominar tanto o código-fonte quanto o bytecode amplia significativamente sua compreensão da plataforma Java.

🚀 Avaje: O Guia Definitivo para Conjuntos de Bibliotecas Java que Aceleram seu Desenvolvimento

O Que é o Avaje? Entendendo a Revolução nas Bibliotecas Java

Se você é desenvolvedor Java, sabe que construir aplicativos do zero, embora educativo, muitas vezes implica retrabalho e perda de tempo com soluções para problemas comuns. É aqui que entra o Avaje (anteriormente conhecido como "Avaje Libs"). Não se trata de um framework monolítico, mas sim de um conjunto coeso e moderno de bibliotecas Java de código aberto, projetadas para trabalhar harmoniosamente e eliminar a complexidade desnecessária no desenvolvimento de aplicações server-side, especialmente APIs web e sistemas baseados em microsserviços.

O projeto Avaje nasceu com a filosofia de oferecer uma stack tecnológica mais leve, intuitiva e produtiva do que as opções tradicionais, mantendo o poder e a confiabilidade da JVM. Ele foca em injeção de dependência type-safe, APIs de banco de dados mais simples, validação, serialização JSON e muito mais, tudo com uma API fluente que prioriza a experiência do desenvolvedor.


Os Pilares do Avaje: Conhecendo as Principais Bibliotecas

O ecossistema Avaje é composto por várias bibliotecas especializadas. Vamos explorar as mais importantes.

1. Avaje Inject: Injeção de Dependência sem Anotações Mágicas

A biblioteca Avaje Inject revoluciona o conceito de Injeção de Dependência (DI) em Java. Diferente de outros frameworks que dependem pesadamente de anotações de reflexão em tempo de execução, o Avaje Inject utiliza processamento de anotações em tempo de compilação. Isso significa que a verificação de dependências, a geração do grafo de componentes e a descoberta de erros acontecem durante a compilação, não em produção. O resultado? Startup mais rápido, código mais seguro e previsível, e zero overhead de reflexão para a injeção.


2. Avaje JSON: Serialização Rápida e Type-Safe

Trabalhar com JSON em Java pode ser verboso. O Avaje JSON oferece uma API de serialização e desserialização que é ao mesmo tempo poderosa e simples. Ele gera código em tempo de compilação para converter seus objetos Java em JSON e vice-versa, garantindo alto desempenho e evitando os erros comuns de reflection. Sua API builder e de leitura também são extremamente intuitivas para manipulação dinâmica de documentos JSON.


3. JPA Alternativo: Avaje Database

Para muitos, o JPA (com Hibernate) pode ser complexo e gerar comportamentos inesperados. O Avaje Database (também conhecido como Ebean) é uma ORM (Object-Relational Mapper) diferente. Ele adota uma abordagem mais declarativa e menos intrusiva, com foco em consultas type-safe (usando Query Beans gerados em tempo de compilação), suporte nativo a migrações de banco de dados (via DbMigration) e um modelo de transação mais simples. É uma opção robusta para quem busca produtividade e controle.


Por Que Considerar o Avaje para seu Próximo Projeto?

Produtividade do Desenvolvedor

A integração perfeita entre as bibliotecas, a documentação clara e o foco em APIs intuitivas significam que você passa menos tempo configurando e lutando com o framework, e mais tempo implementando lógica de negócio.


Desempenho Superior

A estratégia agressiva de uso de processamento de anotações (annotation processing) em tempo de compilação elimina a maioria das reflexões, resultando em aplicativos que inicializam em milissegundos e consomem menos memória. Ideal para ambientes serverless e de containers.


Simplicidade e Clareza

O Avaje evita a "mágica" excessiva. O código gerado é visível e o funcionamento das bibliotecas é mais transparente, facilitando a depuração e a compreensão do fluxo da aplicação por toda a equipe.


Stack Moderna e Coesa

Ao invés de juntar dezenas de bibliotecas de provedores diferentes (com possíveis conflitos), você adota um conjunto integrado e testado para as necessidades centrais de uma aplicação backend, desde a injeção de dependência até a camada de persistência.


Como Começar com o Avaje? Primeiros Passos

Iniciar é simples, especialmente se você usar um gerenciador de dependências como Maven ou Gradle. Para um projeto web básico, você normalmente adicionaria as dependências do Avaje Inject, Avaje JSON e, opcionalmente, do Avaje Database. O site oficial (avaje.io) oferece guias de início rápido detalhados. A comunidade, embora em crescimento, é ativa e o criador do projeto (Rob Bygrave) é muito presente, garantindo um suporte de qualidade.


Conclusão: Uma Alternativa Sólida e Moderna

O Avaje representa um salto de qualidade no desenvolvimento Java moderno. Se você busca uma stack que prioriza desempenho, produtividade e simplicidade sem abrir mão do poder da JVM, vale a pena investir tempo para conhecê-lo. Ele é particularmente atraente para novos projetos, APIs REST/GraphQL e sistemas onde o tempo de startup e a eficiência de recursos são críticos. Experimente, e você pode descobrir uma forma mais prazerosa e eficiente de codar em Java. 🎯

segunda-feira, 5 de janeiro de 2026

🚀 Java 25: O Que Esperar da Próxima Grande Versão da Plataforma Java?

Java 25: Olhando Para o Horizonte da Plataforma

O mundo do desenvolvimento Java está sempre em evolução, e a comunidade já começa a especular e acompanhar os primeiros indícios do que será o JDK 25. Seguindo o ciclo de lançamentos semestrais estabelecido pela Oracle, o Java 25 promete trazer novas features, melhorias de performance e refinamentos nas APIs que sustentam milhões de aplicações em todo o mundo. Neste post, exploramos o que se pode esperar desta versão, baseado no processo de desenvolvimento aberto do OpenJDK.


📅 O Ciclo de Lançamentos e o Roadmap do JDK 25

Com o modelo de lançamento rápido (six-month release cadence), o Java 25 está previsto para ser lançado em março de 2025, como sucessor do JDK 24. É crucial entender que, nesta fase, as funcionalidades ainda estão em proposta e desenvolvimento ativo no Project Amber, Project Valhalla, Project Loom e outros incubator modules. As JEPs (JDK Enhancement Proposals) que integrarão oficialmente a versão 25 serão definidas e priorizadas ao longo dos próximos meses pela comunidade de desenvolvedores.


🔍 Possíveis Recursos e Melhorias em Discussão

Embora a lista final de JEPs para o Java 25 ainda não esteva fechada, podemos olhar para as propostas em estágio de preview, incubação ou discussão ativa nas versões anteriores (JDK 21 ao 24) para prever o que pode amadurecer e ser promovido. Algumas áreas de interesse incluem:

Continuidade das Inovações em Concorrência e Modelo de Threads

Os Virtual Threads (Project Loom), lançados de forma definitiva no Java 21, continuam recebendo refinamentos. No JDK 25, é possível esperar otimizações adicionais na performance, debugging e integração com frameworks e bibliotecas do ecossistema, consolidando ainda mais este modelo revolucionário para lidar com concorrência.

Evolução do Sistema de Tipos e Modelo de Memória

O Project Valhalla, que busca introduzir value objects e classes primitivas especializadas, pode dar mais um passo significativo. A introdução de primitive classes em estágio preview é uma possibilidade concreta, prometendo melhorias dramáticas de performance e uso de memória para tipos de dados simples.

Refinamentos na Sintaxe (Project Amber)

O Project Amber tem sido responsável por tornar o Java mais conciso e expressivo. Constructos como pattern matching para switch e registros (records) podem ganhar novas capacidades, como padrões aninhados mais poderosos ou a evolução dos sealed classes.


⚙️ Impacto para Desenvolvedores e Empresas

A adoção do Java 25, como qualquer nova versão, deve ser planejada. A boa notícia é que o modelo de lançamento semestral com LTS (Long-Term Support) a cada seis versões (sendo a próxima LTS o Java 27) oferece flexibilidade. Desenvolvedores podem testar as novas features em estágio preview sem comprometer a estabilidade de produção. Manter-se atualizado com as versões não-LTS, como a 25, permite experimentar inovações rapidamente, preparando a base de código para a futura migração para uma versão LTS.


🔧 Como Acompanhar o Desenvolvimento do Java 25

Para ficar por dentro das novidades em tempo real, a melhor fonte é o site oficial do OpenJDK. Lá você pode acompanhar o painel de JEPs destinadas ao JDK 25, acessar builds early-access e participar de listas de discussão. Outro canal valioso são as comunidades Java, como a Java Community Process (JCP) e fóruns de desenvolvedores, onde as propostas são debatidas.


🎯 Conclusão: Preparando-se para o Futuro

O Java 25 representa mais um capítulo na contínua modernização de uma das plataformas de desenvolvimento mais críticas do mundo. Embora suas features definitivas ainda estejam se moldando, uma coisa é certa: a linguagem continua evoluindo com foco em produtividade, performance e segurança. Para o desenvolvedor Java, acompanhar essas mudanças não é só sobre aprender uma nova sintaxe, mas sobre compreender as novas abstrações e paradigmas que estarão disponíveis para construir a próxima geração de aplicações escaláveis, eficientes e robustas. Fique de olho nas prévias e comece seus testes!

🔧 Como Usar Condicionais If/Else em Makefiles no Linux – Guia Prático

🔧 Introdução a Condicionais em Makefiles

Makefiles são ferramentas essenciais para automação de compilação em ambientes Linux, permitindo definir regras e dependências para construção de projetos. Um dos recursos mais poderosos, porém menos explorados por iniciantes, é o uso de condicionais if/else. Eles permitem tomar decisões dinâmicas durante o processo de build, adaptando-se a diferentes ambientes, arquiteturas ou parâmetros fornecidos pelo usuário.


📝 Sintaxe Básica dos Condicionais

A estrutura condicional em um Makefile segue uma lógica específica, diferente de linguagens de programação convencionais. Ela é baseada em diretivas que são avaliadas durante a fase de leitura do Makefile, antes da execução das regras.


⚙️ A Estrutura ifeq e ifneq

A diretiva ifeq (if equal) verifica se dois valores são idênticos. Sua forma básica é:

ifeq (arg1, arg2)
    # comandos se verdadeiro
else
    # comandos se falso
endif

Por exemplo, para verificar o sistema operacional alvo:

ifeq ($(OS),Linux)
    CC=gcc
else
    CC=clang
endif

Já a diretiva ifneq (if not equal) faz o inverso, executando o bloco se os argumentos forem diferentes.


🔎 Condicionais com ifdef e ifndef

Essas diretivas verificam se uma variável está definida (e não vazia) ou não. São extremamente úteis para flags opcionais.

ifdef DEBUG
    CFLAGS += -g -O0
else
    CFLAGS += -O2
endif

ifndef é seu complemento, ativando o bloco se a variável não estiver definida.


🚀 Exemplo Prático: Compilação Condicional

Vamos criar um exemplo real. Suponha um projeto que pode ser compilado para produção (release) ou desenvolvimento (debug).

# Defina TARGET=debug para habilitar modo de depuração
TARGET ?= release

ifeq ($(TARGET), debug)
    CFLAGS = -Wall -g -DDEBUG
    BIN_NAME = meuapp_debug
else
    CFLAGS = -Wall -O3
    BIN_NAME = meuapp
endif

todos: $(BIN_NAME)

$(BIN_NAME): main.c
    $(CC) $(CFLAGS) -o $@ $^

Ao executar make TARGET=debug, o Makefile usará as flags de depuração. O comando simples make usará a configuração otimizada de release.


⚠️ Pontos de Atenção e Boas Práticas

1. Avaliação Imediata: Os condicionais são avaliados no momento da leitura do Makefile, não durante a execução das regras. Variáveis definidas dentro de comandos de regra não afetam condicionais superiores.

2. Espaçamento: A sintaxe é sensível a espaços. Não adicione espaços após as vírgulas nos argumentos de ifeq.

3. Combine com Funções: Use funções como $(filter) ou $(findstring) dentro de condicionais para lógicas mais complexas.


🎯 Conclusão

Dominar condicionais if/else em Makefiles é um passo fundamental para criar sistemas de build robustos e flexíveis no Linux. Eles permitem adaptar a compilação a múltiplos cenários, tornando seu projeto mais portátil e fácil de manter. Comece com exemplos simples, como a escolha entre debug/release, e gradualmente incorpore condições mais complexas para gerenciar dependências ou diferentes plataformas de destino.

🚀 Novidades do Spring Boot 4 e Spring Framework 7 para Desenvolvedores

🌟 Introdução: A Nova Fase do Ecossistema Spring

Em 2025, o ecossistema Spring dá mais um passo significativo em sua jornada de modernização com o lançamento do Spring Boot 4 e do Spring Framework 7. Se a versão anterior representou uma mudança de pilar com a migração para o Jakarta EE, essas novas releases consolidam essa base, trazendo melhorias focadas em produtividade do desenvolvedor, suporte resiliente nativo e uma experiência ainda mais refinada para a construção de aplicações cloud-native.


📋 Atualizações da Base Técnica

Antes de explorar as novas funcionalidades, é crucial entender a nova fundação sobre a qual esses frameworks são construídos.

Versões Mínimas e Recomendadas

O Java 17 permanece como requisito mínimo. No entanto, para aproveitar ao máximo os novos recursos da JVM, como virtual threads, o uso do Java 21 ou Java 25 é fortemente recomendado.

Alinhamento com Jakarta EE 11

O Spring Framework 7 adota completamente o padrão Jakarta EE 11. Isso significa uma atualização para Servlet 6.1, JPA 3.2 e Bean Validation 3.1, garantindo melhor compatibilidade e suporte às especificações mais recentes da plataforma Enterprise Java.

Suporte ao Kotlin 2.2+

Para desenvolvedores Kotlin, o suporte foi elevado para a versão 2.2 e superiores, trazendo uma integração mais suave com corrotinas e tornando o trabalho com código reativo ainda mais natural.


⚙️ O que há de novo no Spring Boot 4

A quarta versão principal do Spring Boot aprimora seu papel como a base ideal para aplicações Java modernas, com foco em desempenho, observabilidade e manutenibilidade.

🔄 Melhorias em Imagens Nativas (GraalVM)

O suporte a imagens nativas do GraalVM foi significativamente aprimorado e está totalmente alinhado com a GraalVM 24. O processamento AOT (Ahead-of-Time) foi otimizado, resultando em tempos de construção mais rápidos e uma pegada de memória reduzida na inicialização. Um avanço notável são os AOT Repositories do Spring Data, que transformam métodos de consulta em código fonte durante a compilação.

📊 Observabilidade: Micrometer 2 e OpenTelemetry

A observabilidade é um pilar para aplicações cloud-native. O Spring Boot 4 faz upgrade para o Micrometer 2 e integra um starter do OpenTelemetry, fazendo com que traços, logs e métricas funcionem perfeitamente juntos, diretamente "out of the box".

🔒 Relatório de Saúde SSL Aprimorado

Para facilitar o monitoramento de certificados em ambientes de produção, o relatório de saúde de SSL agora inclui uma entrada expiringChains que lista certificados próximos da expiração. O status confuso WILL_EXPIRE_SOON foi removido; em vez disso, esses certificados são reportados simplesmente como VALID, evitando alarmes falsos.

🧩 Modularização Interna

Uma mudança arquitetural importante é a refatoração do código base em uma estrutura mais modular. Auto-configurações e códigos de suporte foram divididos em módulos menores e focados. Isso resulta em:

  • Construções e geração de imagens nativas mais rápidas.
  • Gerenciamento de dependências mais limpo.
  • Melhor capacidade de manutenção para a equipe do Spring.

Para a maioria dos desenvolvedores que usam starters (como spring-boot-starter-data-jpa), essa mudança é transparente e não exige alterações no pom.xml ou build.gradle.

🛠️ Nova Anotação @ConfigurationPropertiesSource

Para melhorar o suporte a projetos modulares, foi introduzida a anotação @ConfigurationPropertiesSource. Ela atua como uma dica para o spring-boot-configuration-processor em tempo de construção, garantindo que metadados completos sejam gerados para classes de propriedades de configuração, mesmo quando dependem de tipos base definidos em outros módulos.


⚡ Principais Funcionalidades do Spring Framework 7

O Spring Framework 7 chega com um mix de funcionalidades há muito solicitadas e refinamentos em testes, design de API e infraestrutura central.

🧪 Melhorias em Testes

Duas novidades se destacam:

  1. Pausa do Contexto de Teste: Agora é possível pausar e retomar contextos armazenados no cache, economizando memória e acelerando a execução de grandes suites de testes de integração.
  2. Novo RestTestClient: Um cliente para testar endpoints REST de forma semelhante ao WebTestClient, mas sem a necessidade de incluir infraestrutura reativa nas dependências, simplificando testes de controladores MVC.

🔢 Versionamento de API Nativo

Uma das funcionalidades mais aguardadas! O framework agora oferece suporte nativo para versionamento de APIs, eliminando a necessidade de soluções caseiras. É possível especificar a versão diretamente na anotação de mapeamento:

@GetMapping(version = "1", produces = MediaType.TEXT_PLAIN_VALUE)
public String sayHelloV1() {
    return "Hello World";
}

O Spring pode resolver a versão automaticamente com base em diferentes estratégias configuráveis: por segmento do caminho (/api/v1/...), parâmetro de query, cabeçalho de requisição ou cabeçalho de media type.

🤝 Cliente HTTP Declarativo com @HttpServiceClient

Inspirado no Feign, mas mais leve e totalmente integrado, o @HttpServiceClient permite criar clientes HTTP declarativos. Basta definir uma interface com anotações como @GetExchange, e o Spring cuida da implementação.

@HttpServiceClient("christmasJoy")
public interface ChristmasJoyClient {
    @GetExchange("/greetings?random")
    String getRandomGreeting();
}

🛡️ Anotações de Resiliência Integradas

Padrões de resiliência agora são parte do framework. É possível anotar métodos com @Retryable (para novas tentativas) e @ConcurrencyLimit (para limitar concorrência) diretamente:

@GetExchange("/greetings?random")
@Retryable(maxAttempts = 3, delay = 100, multiplier = 2, maxDelay = 1000)
@ConcurrencyLimit(3)
String getRandomGreeting();

Essas anotações são ativadas ao adicionar @EnableResilientMethods em uma configuração, simplificando muito a adição de padrões de resiliência sem bibliotecas externas.

⛓️ Múltiplos Beans TaskDecorator

Para personalizar a execução de tarefas assíncronas (como propagar contexto de segurança ou logs), agora é possível declarar múltiplos beans do tipo TaskDecorator. O Spring os compõe automaticamente em uma cadeia, na ordem definida por @Order, eliminando a necessidade de criar um decorador composto manualmente.


🎯 Conclusão

O Spring Boot 4 e o Spring Framework 7 representam uma evolução consistente e poderosa do ecossistema. Eles não quebram paradigmas de forma abrupta, mas consolidam a fundação estabelecida nas versões anteriores (Java 17+, Jakarta EE) enquanto introduzem ferramentas práticas que resolvem dores reais dos desenvolvedores.

Desde a observabilidade integrada e os testes mais eficientes até o versionamento nativo de API e os clientes HTTP declarativos, essas releases são impulsionadas pela produtividade no dia a dia. Se você já está na jornada Spring Boot 3, a migração deve ser suave. Se ainda não deu o salto, agora é o momento perfeito para começar a construir no estado da arte do Java moderno.

O futuro do Spring continua brilhante, focado em ajudar desenvolvedores a criar aplicações robustas, observáveis e prontas para a nuvem com menos boilerplate e mais prazer em programar. 💻✨

🚀 Java 21: Guia Completo das Novidades e Como Migrar

Introdução: O Java 21 Chegou como um LTS Revolucionário

Lançada em setembro de 2023, a versão Java 21 não é apenas mais uma atualização. Ela marca um Long-Term Support (LTS), o que significa que é uma versão de suporte estendido, recomendada para produção por anos. A Oracle consolidou nela um conjunto de features preview que estavam em desenvolvimento, trazendo algumas das mudanças mais significativas e aguardadas pela comunidade desde o projeto Loom.


🌟 As Principais Inovações do Java 21

A versão 21 apresenta 15 JEPs (JDK Enhancement Proposals). Vamos mergulhar nas mais impactantes para o dia a dia do desenvolvedor.

🧵 Virtual Threads: Revolução na Concorrência

Finalmente saíram do modo preview! As Virtual Threads (projeto Loom) representam um novo modelo de concorrência leve. Diferente das platform threads (threads do sistema operacional), são threads gerenciadas pela JVM, extremamente leves e em grande número. Isso permite escrever código concorrente no estilo thread-per-request de forma eficiente, sem o overhead tradicional. Ideal para aplicações de alto throughput, como APIs e serviços web.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        System.out.println("Hello from a virtual thread!");
    });
}

🎭 Pattern Matching para Switch (Finalizado)

O Pattern Matching para switch foi finalizado, permitindo uma sintaxe muito mais limpa e expressiva. Agora é possível fazer a desestruturação de objetos diretamente na cláusula case.

String formatter(Object obj) {
    return switch (obj) {
        case Integer i -> String.format("int %d", i);
        case String s -> String.format("String %s", s);
        case null -> "Oops, null!"; // Guarda contra NullPointerException
        default -> obj.toString();
    };
}

📚 Sequenced Collections: Nova Interface para Ordem

Uma nova família de interfaces (SequencedCollection, SequencedSet, SequencedMap) foi introduzida para fornecer operações consistentes em coleções ordenadas. Métodos como getFirst(), getLast(), addFirst(), e reversed() agora têm um contrato claro.

SequencedCollection list = new ArrayList<>();
list.add("B");
list.addFirst("A"); // Adiciona no início
list.getLast(); // Retorna "B"

🛠️ Como Começar a Usar o Java 21

Migrar para o Java 21 é um processo geralmente simples, especialmente se você já está em uma versão LTS anterior (11 ou 17).

1. Baixar o JDK 21

Faça o download do JDK 21 diretamente do site da Oracle, da Adoptium (Eclipse Temurin) ou use gerenciadores como SDKMAN! (sdk install java 21-tem).

2. Atualizar seu Build Tool

No Maven ou Gradle, atualize a configuração do compilador para a versão 21 (<release>21</release> ou sourceCompatibility = JavaVersion.VERSION_21).

3. Testar as Novas Features

Comece implementando Virtual Threads em pontos de I/O da sua aplicação ou refatorando switches complexos com o novo Pattern Matching. A migração costuma ser incremental e não requer mudanças drásticas.


🔍 Benefícios de Longo Prazo e Conclusão

Adotar o Java 21 LTS vai além de usar features novas. É um investimento em performance (com as Virtual Threads), segurança (com atualizações de segurança garantidas) e legibilidade do código. A JVM continua evoluindo com melhorias de garbage collector (ZGC e Shenandoah) e desempenho.

O Java 21 solidifica a linguagem como uma plataforma moderna, ágil e preparada para os desafios de arquiteturas concorrentes e distribuídas da atualidade. A migração é altamente recomendada e representa o futuro do ecossistema Java.

E aí, preparado para atualizar seu projeto? 🚀

quarta-feira, 8 de setembro de 2021

🚀 Apresentando o Java SE 10

🚀 Apresentando o Java SE 10

Nos últimos 22 anos, o Java cresceu até se tornar uma comunidade vibrante que atingiu uma escala sem igual. O Java continua a trazer valor para desenvolvedores e empresas em todo o mundo. Um planejamento cuidadoso e o envolvimento do ecossistema ajudaram o Java a se tornar uma das linguagens de programação mais usadas do planeta. Com mais de 12 milhões de desenvolvedores em todo o mundo executando Java, ele continua sendo a linguagem de programação número 1 escolhida por programadores de software. Daqui para frente, o objetivo é garantir que o Java esteja bem posicionado para o desenvolvimento moderno e o crescimento na nuvem.


Em 2017, foi anunciada a intenção de mudar para um novo ciclo de lançamentos de seis meses para o Java, com o objetivo de reduzir a latência entre os lançamentos principais. Ao mesmo tempo, foram anunciados os planos para construir e distribuir binários do OpenJDK. Este modelo de lançamento é inspirado nos modelos de lançamento usados por outras plataformas e por várias distribuições de sistemas operacionais, atendendo ao cenário moderno de desenvolvimento de aplicativos. O ritmo da inovação está acontecendo em uma taxa cada vez maior, e este novo modelo de lançamento permitirá que os desenvolvedores aproveitem novos recursos em produção o mais rápido possível. O desenvolvimento moderno de aplicativos espera um licenciamento aberto simples e um ritmo previsível baseado no tempo, e o novo modelo de lançamento atende a ambos.


Com isso, temos o prazer de anunciar a disponibilidade geral do Java 10, o primeiro lançamento com prazo definido como parte do novo ciclo de lançamentos de seis meses. Esta versão é mais do que uma simples correção de estabilidade e desempenho em relação ao Java SE 9; na verdade, ela introduz doze novos aprimoramentos definidos através das JDK Enhancement Proposals (JEPs) que os desenvolvedores podem começar a usar imediatamente:

⚙️ Principais Aprimoramentos (JEPs)

  • (JEP 286) Inferência de Tipo para Variáveis Locais: Estende a inferência de tipo para declarações de variáveis locais com inicializadores. Ele introduz
    var
    no Java, algo comum em outras linguagens.
  • (JEP 296) Consolidar a Floresta JDK em um Único Repositório: Combina os numerosos repositórios da floresta JDK em um único repositório para simplificar e agilizar o desenvolvimento.
  • (JEP 204) Interface do Coletor de Lixo: Melhora o isolamento do código-fonte de diferentes coletores de lixo, introduzindo uma interface de coletor de lixo (GC) limpa.
  • (JEP 307) GC Completo Paralelo para o G1: Melhora as latências do pior caso do G1 tornando a coleta de lixo (GC) completa paralela.
  • (JEP 301) Compartilhamento de Dados de Classe de Aplicativo: Para melhorar a inicialização e a pegada de memória, estende o recurso existente de Compartilhamento de Dados de Classe ("CDS") para permitir que classes de aplicativo sejam colocadas no arquivo compartilhado.
  • (JEP 312) Aperto de Mãos Local por Thread: Introduz uma maneira de executar um callback em threads sem executar um ponto seguro global da VM. Torna possível e barato parar threads individuais, e não apenas todos os threads ou nenhum.
  • (JEP 313) Remover a Ferramenta Geradora de Cabeçalho Nativo: Remove a ferramenta
    javah
    do JDK, uma vez que ela foi superada por funcionalidades superiores no
    javac
    .
  • (JEP 314) Extensões Adicionais de Tag de Idioma Unicode: Aprimora
    java.util.Locale
    e APIs relacionadas para implementar extensões Unicode adicionais de tags de idioma BCP 47.
  • (JEP 316) Alocação de Heap em Dispositivos de Memória Alternativos: Permite que a HotSpot VM aloque o heap de objetos Java em um dispositivo de memória alternativo, como um NV-DIMM, especificado pelo usuário.
  • (JEP 317) Compilador JIT Experimental Baseado em Java: Permite que o compilador JIT baseado em Java, Graal, seja usado como um compilador JIT experimental na plataforma Linux/x64.
  • (JEP 319) Certificados Raiz: Fornece um conjunto padrão de certificados de Autoridade de Certificação (CA) raiz no JDK.
  • (JEP 322) Versionamento de Lançamento Baseado em Tempo: Revisa o esquema da string de versão da Plataforma Java SE e do JDK, e informações de versionamento relacionadas, para os modelos de lançamento baseados em tempo atuais e futuros.

🌍 O Ecossistema Java

O ecossistema Java continua a ser uma coleção diversificada de desenvolvedores e sua participação contínua é bem-vinda para ajudar a moldar o futuro do Java.

🚀 Apresentando o Java SE 11

Baixe o Java 11

O tempo voa! Nos últimos meses, foram anunciadas mudanças para evoluir a plataforma Java, garantindo que ela continue avançando com um futuro promissor para os usuários. Esses avanços incluíram:


Acelerando o Ritmo e a Previsibilidade das Entregas

Desde o lançamento do Java 9, a plataforma Java mudou para um ciclo de lançamento de seis meses, permitindo que os desenvolvedores tenham acesso mais rápido a melhorias contínuas. Os lançamentos agora ocorrem em março e setembro de cada ano, o que significa que não é mais necessário tentar absorver centenas de mudanças a cada dois anos de uma só vez – em vez disso, as mudanças são entregues em um ritmo mais mensurado e previsível.


Tornando o Java Ainda Mais Aberto

Para melhorar a produtividade dos desenvolvedores, recursos comerciais anteriormente acessíveis apenas com uma licença paga foram disponibilizados como código aberto. Isso cria maior alinhamento e intercambialidade entre as versões do Oracle JDK e do Oracle OpenJDK. Recursos comerciais anteriores agora disponíveis no OpenJDK incluem Application Class Data Sharing, o Project ZGC, o Java Flight Recorder (JFR) e o Java Mission Control (JMC). Mais recentemente, foram anunciados planos para disponibilizar a tecnologia JMC como um download separado para atender tanto aos usuários do OpenJDK quanto do Oracle JDK.


Introduzindo a Assinatura Java SE

Foi anunciada a Java SE Subscription, um novo modelo que cobre todas as necessidades de licenciamento e suporte do Java SE para dar ainda mais suporte aos milhões de empresas em todo o mundo que executam Java em produção. A assinatura complementa a oferta gratuita de longa data do Oracle OpenJDK, que atende desenvolvedores e organizações que não precisam de suporte comercial.


🆕 O Java 11 já está disponível

Com seis meses desde o Java 10 (o primeiro lançamento de recursos como parte do ciclo de seis meses), o Java 11 já está disponível.

O Oracle fornece o JDK não apenas sob a versão Oracle OpenJDK usando a licença de código aberto GNU General Public License v2, com a Classpath Exception (GPLv2+CPE), mas também sob uma licença comercial para quem usa o Oracle JDK como parte de um produto ou serviço Oracle, ou que não deseja usar software de código aberto. Estas substituem a histórica licença "BCL", que tinha uma combinação de termos comerciais gratuitos e pagos.

Isso significa que os usuários podem obter o Java 11 de acordo com suas necessidades:

  • Java 11 é uma versão de suporte de longo prazo (LTS). Isso significa que usuários mais conservadores com a adoção da plataforma e que exigem suporte de longo prazo podem licenciar os binários do Oracle JDK por meio da oferta Java SE Subscription. Permite que os usuários recebam atualizações na versão LTS do Java 11 por pelo menos oito anos. A assinatura fornece acesso a atualizações testadas e certificadas de desempenho, estabilidade e segurança para o Java SE, diretamente da Oracle. Também inclui acesso ao My Oracle Support (MOS) 24x7, suporte em 27 idiomas, recursos de gerenciamento, monitoramento e implantação do Java SE 8 Desktop, entre outros benefícios.
  • Usuários que preferem acesso rápido a novos aprimoramentos podem continuar usando a versão Oracle OpenJDK. Como foi o caso do Java 9 e Java 10, os usuários desta versão obtêm builds OpenJDK de código aberto, totalmente testadas e fornecidas pela Oracle.

🌟 Principais Aprimoramentos do Java 11

Dezessete aprimoramentos foram entregues no Java 11, incluindo mais notavelmente:

JEP 321 – Cliente HTTP (Padrão)

Este JEP padroniza a API de Cliente HTTP incubada introduzida no JDK 9, via JEP 110, e atualizada no JDK 10.

JEP 332 – Transport Layer Security (TLS) 1.3

O TLS 1.3 é uma grande reformulação do protocolo TLS e fornece melhorias significativas de segurança e desempenho em relação às versões anteriores.

JEP 328 – Java Flight Recorder (JFR)

O JFR fornece um mecanismo de gravação de alto desempenho e uma estrutura de coleta de dados de baixa sobrecarga para solução de problemas de aplicativos Java críticos.

// Exemplo de código com o JFR (conceitual)
// O JFR permite iniciar gravações para diagnóstico
try (Recording recording = new Recording()) {
    recording.start();
    // Seu código da aplicação aqui
    recording.stop();
    recording.dump(Paths.get("my-recording.jfr"));
}

JEP 333 – Project ZGC

O ZGC é um coletor de lixo (GC) experimental, mas previsível e de baixa latência, que pode lidar com heaps que variam de relativamente pequenos (algumas centenas de megabytes) a muito grandes (muitos terabytes) de tamanho.

JEP 330 – Executar Programas de Código-Fonte de Arquivo Único

Este aprimoramento simplifica a "entrada" para novos usuários Java, melhorando o launcher java para executar um programa fornecido como um único arquivo de código-fonte Java, incluindo o uso dentro de um script e/ou técnicas relacionadas. Por exemplo, um arquivo chamado HelloWorld.java contendo:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Olá, mundo!");
    }
}

Agora pode ser executado diretamente com:

java HelloWorld.java

🔮 Olhando para o Futuro

Agora que o Java 11 está geralmente disponível, o desenvolvimento mudou para o próximo lançamento de recursos de seis meses, na forma do Java 12, atualmente com duas melhorias direcionadas e mais a serem adicionadas à medida que o trabalho for concluído.

Com 12 milhões de desenvolvedores em todo o mundo usando Java, o Java continua sendo a linguagem de programação número 1 escolhida pelos programadores de software. E como o Java 11 demonstra, por meio de um planejamento contínuo e cuidadoso e do envolvimento do ecossistema, a plataforma Java está bem posicionada para o desenvolvimento moderno e o crescimento na nuvem.

🚀 A Chegada do Java 12!

🚀 A Chegada do Java 12!

Após o lançamento do Java 9 em 2017, o ritmo de lançamentos da plataforma Java mudou de uma versão principal a cada 3+ anos para uma versão com novos recursos a cada seis meses. Isso fornece aos desenvolvedores um acesso mais previsível a melhorias contínuas. As versões com novos recursos agora ocorrem de forma confiável em março e setembro de cada ano. Chega de tentar gerenciar centenas de mudanças a cada dois anos de uma só vez – em vez disso, a mudança é entregue em um ritmo mais granular, rápido e gerenciável.


O Java 12 já está disponível!

A Oracle agora oferece o Java 12 para empresas e desenvolvedores. O JDK 12 receberá, no mínimo, duas atualizações, de acordo com o cronograma de CPU da Oracle, antes de ser seguido pelo Oracle JDK 13, previsto para setembro de 2019.

A Oracle fornece o Java 12 como a versão Oracle OpenJDK usando a licença de código aberto GNU General Public License v2, com a Classpath Exception (GPLv2+CPE), e também sob uma licença comercial para quem usa a versão Oracle JDK como parte de um produto ou serviço Oracle, ou que não deseja usar software de código aberto.


Java 12, Juntos

Semelhante ao Java 11, vale a pena celebrar as contribuições feitas para o Java 12 por muitos indivíduos e organizações na Comunidade OpenJDK — todos nós construímos o Java, juntos!

Proporção de Correções no JDK 12

A taxa geral de mudança no JDK ao longo do tempo permaneceu essencialmente constante por muitos anos, mas, sob o ritmo de seis meses, a velocidade na qual as inovações são entregues aos desenvolvedores melhorou muito. Em vez de disponibilizar dezenas de milhares de correções e cerca de cem JEPs em uma grande versão principal a cada poucos anos, os aprimoramentos são disponibilizados em versões de recursos menores em um cronograma previsível e mais gerenciável de seis meses. Essas mudanças podem variar de um recurso significativo a pequenas melhorias, manutenção de rotina, correções de bugs e melhorias na documentação. Cada uma dessas alterações é representada em um único commit para um único problema no JDK Bug System.

Dos 1.919 problemas do JIRA marcados como corrigidos no JDK 12, 1.433 foram concluídos por pessoas que trabalham para a Oracle, enquanto 486 foram contribuições de desenvolvedores individuais e desenvolvedores que trabalham para outras organizações. Analisar os problemas e compilar os dados da organização dos responsáveis resulta no seguinte gráfico de organizações que patrocinam o desenvolvimento de correções no JDK 12:

Embora os desenvolvedores empregados pela Oracle tenham resolvido 75% dos problemas do JIRA durante o desenvolvimento do JDK 12, 25% foram corrigidos por desenvolvedores que trabalham para outras organizações. Desenvolvedores que trabalham para as cinco próximas maiores organizações contribuintes, Red Hat (8%), Google (6%), SAP (4%), BellSoft (1%) e IBM (1%), corrigiram coletivamente 20% desses problemas. Desenvolvedores independentes contribuíram com 3% das correções no JDK 12.

Por último, mas não menos importante, os dois por cento restantes das correções foram contribuídos coletivamente por desenvolvedores de uma ampla gama de organizações, incluindo Alibaba, Amazon, ARM, Azul, Huawei, Intel, JetBrains, Linaro e Twitter.

Agradecimentos especiais também aos muitos desenvolvedores experientes que revisaram as mudanças propostas, aos primeiros usuários que testaram as compilações de acesso antecipado e relataram problemas, e aos profissionais dedicados que forneceram feedback nas listas de e-mail do OpenJDK.


🔧 Novos Aprimoramentos no Java 12

Oito melhorias são entregues com o Java 12:

JEP 325 – Switch Expressions (preview)

Estende a instrução switch para que possa ser usada como uma instrução ou uma expressão, e que ambas as formas possam usar um comportamento de escopo e fluxo de controle "tradicional" ou "simplificado". Essas mudanças simplificarão a codificação do dia a dia e também prepararão o caminho para o uso de correspondência de padrões (JEP 305) no switch. Para o JDK 12, esse recurso está disponível como um recurso de linguagem de visualização (JEP 12).

JEP 344 – Abortable Mixed Collections for G1

Torna as coletas mistas do G1 abortáveis se elas excederem o alvo de pausa.

JEP 346 – Promptly Return Unused Committed Memory from G1

Aprimora o coletor de lixo G1 para retornar automaticamente a memória do heap Java para o sistema operacional quando ociosa.

JEP 189 – Shenandoah, A Low-Pause-Time Garbage Collector (experimental)

Adiciona um novo algoritmo de coleta de lixo (GC) que reduz os tempos de pausa do GC fazendo o trabalho de evacuação simultaneamente com os threads Java em execução.

JEP 230 – Microbenchmark Suite

Adiciona um conjunto básico de microbenchmarks ao código-fonte do JDK e facilita para os desenvolvedores executar microbenchmarks existentes e criar novos.

JEP 334 – JVM Constants API

Introduz uma API para modelar descrições nominais de artefatos principais de arquivo de classe e tempo de execução, em particular constantes que podem ser carregadas do pool de constantes.

JEP 340 – One AArch64 Port, Not Two

Remove todas as fontes relacionadas à porta arm64, mantendo a porta ARM de 32 bits e a porta aarch64 de 64 bits.

JEP 341 – Default CDS Archives

Aprimora o processo de construção do JDK para gerar um arquivo de compartilhamento de dados de classe (CDS), usando a lista de classes padrão, em plataformas de 64 bits.


Com 12 milhões de desenvolvedores em todo o mundo, o Java continua sendo a linguagem de programação nº 1 de escolha dos programadores de software. E como a entrega pontual de melhorias com o Java 12 demonstra, por meio de um planejamento contínuo e cuidadoso e envolvimento do ecossistema, a plataforma Java está bem posicionada para o desenvolvimento moderno e crescimento na nuvem.

📦 As Ofertas do Java SE: Um Guia para Desenvolvedores

🧭 O Ecossistema do Java SE

O ecossistema Java é incrivelmente diverso. Ele alimenta bilhões de dispositivos e servidores e é fundamental para a infraestrutura de nuvem em todo o mundo. Apenas a Plataforma Java, Standard Edition, ou "Java SE", que é a plataforma Java central para computação de uso geral, já possui uma grande diversidade.


📂 As Principais Áreas das Ofertas Java SE

1) OpenJDK

O OpenJDK é o local onde ocorre a colaboração para o desenvolvimento de uma implementação de código aberto da Plataforma Java, Standard Edition, e projetos relacionados. O compromisso com o OpenJDK permanece forte, tendo sido recentemente iniciado o projeto JDK 10. O OpenJDK conta com uma ampla participação em todo o ecossistema. A atividade no projeto tem crescido consistentemente.

Por exemplo, a maioria dos principais distribuidores de Linux e outras partes, como Red Hat, Canonical e SUSE, produzem e distribuem binários baseados neste código aberto. O código-fonte está disponível sob a popular licença GNU General Public License v2 (GPLv2), ou seja, é completamente gratuito. Licenças de código-fonte comerciais também estão disponíveis para empresas que desejam licenciar o código-fonte para uma infinidade de propósitos, e dezenas o fizeram.


2) A Implementação Oracle do Java SE ("Oracle JDK" e "Oracle JRE")

O Oracle JRE/JDK é a implementação Oracle do Java SE. Assim como muitas outras empresas fornecem suas implementações do Java SE para seus clientes, a Oracle também o faz. Existem dois canais principais para as distribuições binárias:

  • java.com: Destinado a consumidores que desejam executar o Java Runtime Environment (JRE) em seus computadores pessoais para aplicativos como Minecraft ou outros softwares de consumo baseados em Java.
  • Java Development Kit (JDK) no OTN: Voltado para desenvolvedores e empresas.

Esses binários são gratuitos para a grande maioria dos casos de uso, conforme observado em java.com/license.


3) Oracle Java SE Advanced, Java SE Advanced Desktop, Java SE Suite

Além da implementação central do Java SE, a Oracle também fornece ferramentas e recursos avançados adicionais voltados para usuários corporativos. Esses recursos incluem ferramentas para ajudar a monitorar, gerenciar e implantar Java em um ambiente empresarial, diagnóstico e monitoramento avançado de tempo de execução, bem como acesso a suporte e atualizações para versões legadas do Java SE, como Java SE 6 e Java SE 7.

Esses recursos comerciais são fornecidos como downloads separados. Na medida em que precisam interagir com o Oracle JRE, eles são desativados por padrão nesse produto e podem ser habilitados usando o sinalizador

-XX:+UnlockCommercialFeatures
em tempo de execução na sua JVM. Mais informações sobre recursos comerciais específicos podem ser encontradas na Tabela 1-1 do link oficial da documentação.


4) Java SE Embedded

Conforme observado na seção (2), o Oracle JRE/JDK é gratuito para a maioria dos casos de uso em que é executado em um desktop ou servidor de uso geral. Se um cliente desejar incorporar o Oracle JDK/JRE em um dispositivo de algum tipo (por exemplo, um caixa registradora), a licença BCL gratuita não se aplica. Nesses casos, uma licença comercial de Java SE Embedded precisa ser negociada.

O Java SE Embedded também oferece opções binárias adicionais para dispositivos com recursos limitados e conjuntos de chips mais orientados para sistemas embarcados.

🔒 JDK 8 passará a usar TLS 1.2 como padrão

🚀 O Futuro da Segurança no JDK 8

Uma mudança importante foi anunciada para o JDK 8: a partir de uma atualização futura, o protocolo TLS (Transport Layer Security) 1.2 será habilitado por padrão para conexões cliente.


🔍 Por que essa mudança é importante?

O TLS é um protocolo fundamental para a segurança da comunicação na internet, protegendo dados transmitidos entre aplicações. Atualmente, o JDK 8 usa TLS 1.0 como padrão, uma versão mais antiga e considerada menos segura frente a vulnerabilidades modernas.

A transição para o TLS 1.2 como padrão reforça significativamente a segurança das aplicações Java, alinhando-se com as melhores práticas e os padrões atuais da indústria.


⚙️ O que muda exatamente?

A alteração principal está no valor padrão da propriedade de sistema jdk.tls.client.protocols. Quando essa propriedade não estiver definida, o JDK passará a negociar conexões usando TLS 1.2 por padrão.

O comportamento para conexões de servidor (onde o JDK atua como servidor TLS) permanecerá inalterado.


⚠️ Impacto e Compatibilidade

A maioria dos servidores e serviços modernos já suportam TLS 1.2, portanto, o impacto para a maioria dos usuários deve ser mínimo. No entanto, é importante estar ciente de cenários onde a compatibilidade pode ser afetada:

  • Conectando-se a servidores legados: Aplicações que precisam se comunicar com servidores muito antigos que suportam apenas TLS 1.0 ou 1.1 podem encontrar falhas de conexão.
  • Testes e Desenvolvimento: Ambientes de teste que utilizam servidores com suporte limitado a TLS podem precisar de ajustes.

🛠️ Gerenciando a Mudança e Solucionando Problemas

Para garantir uma transição suave, é possível gerenciar explicitamente os protocolos usados.

1. Verificando o protocolo atualmente em uso:
É possível depurar a conexão para ver qual versão do TLS está sendo negociada.

System.setProperty("javax.net.debug", "ssl:handshake");
// Sua lógica de conexão aqui...

2. Revertendo para o comportamento anterior (NÃO RECOMENDADO):
Se for absolutamente necessário conectar-se a um serviço legado, é possível redefinir o padrão para TLS 1.0 definindo a propriedade de sistema na linha de comando da JVM. Esta é uma solução temporária e compromete a segurança.

java -Djdk.tls.client.protocols="TLSv1" -jar MinhaAplicacao.jar

3. Especificando múltiplos protocolos (Abordagem Preferida):
A abordagem mais robusta é especificar explicitamente uma lista de protocolos suportados, permitindo o uso do TLS 1.2 mas mantendo a compatibilidade com versões anteriores se necessário. Isso pode ser feito programaticamente.

import javax.net.ssl.*;
import java.security.Security;
import java.util.Arrays;

SSLContext context = SSLContext.getInstance("TLS");
context.init(null, null, null);
SSLSocketFactory factory = context.getSocketFactory();
SSLSocket socket = (SSLSocket) factory.createSocket("host", port);

// Definir protocolos explicitamente
socket.setEnabledProtocols(new String[] {"TLSv1.2", "TLSv1.1", "TLSv1"});

🎯 Conclusão

A mudança para TLS 1.2 como padrão no JDK 8 é um passo importante para a segurança do ecossistema Java. Ela protege os usuários e suas aplicações contra ameaças conhecidas em versões mais antigas do TLS.

Desenvolvedores e administradores de sistema devem testar suas aplicações em ambientes que reflitam essa nova configuração padrão para identificar e resolver quaisquer problemas de compatibilidade com antecedência, priorizando sempre a manutenção da segurança.

🚀 Filtrando Dados de Serialização de Entrada – Um pouco da qualidade do JDK 9 disponível agora nas famílias de lançamento atuais

🚀 Filtrando Dados de Serialização de Entrada – Um pouco da qualidade do JDK 9 disponível agora

Uma das novas funcionalidades desenvolvidas para o JDK 9, a JEP 290: Filter Incoming Serialization Data (Filtrar Dados de Serialização de Entrada), foi retroportada para o JDK 8, 7 e 6.


A opção de filtrar dados de serialização de entrada adiciona mais uma camada de proteção e robustez à serialização de objetos. Ao usar o mecanismo de filtragem, os desenvolvedores podem restringir as classes que podem ser desserializadas por um aplicativo. Como a maioria dos recursos de segurança, este novo recurso não se destina a substituir as práticas atuais de codificação segura, mas a complementá-las.


🔄 Disponibilidade e Retroportes

O recurso está disponível nas versões de acesso antecipado do JDK 9, mas como havia o desejo de que os usuários das versões atuais também tivessem essa capacidade, ele já foi retroportado para as atualizações do JDK e JRE lançadas com a Atualização Crítica de Pacotes (Critical Patch Update) de janeiro de 2017 (8u121, 7u131 e 6u141). Consulte as notas de lançamento das versões correspondentes para obter mais informações.


💡 Por Que Este Filtro é Importante?

Implementar um filtro para dados de serialização de entrada é uma etapa proativa para reforçar a segurança de aplicações que dependem de desserialização. Ele age como um guardião, validando o que pode ser reconstruído a partir do fluxo de bytes recebido, ajudando a mitigar potenciais vetores de ataque.

⏰ Entendendo o Time Zone Updater 2.0

Entendendo o Time Zone Updater 2.0

Diferentes lugares do mundo estão em diferentes fusos horários, por isso o Java precisa manter um registro das informações de fuso horário.


Essas informações se tornam complicadas quando se consideram as regras para o Horário de Verão em diferentes regiões. Existem lugares onde as mudanças de Horário de Verão ocorrem várias vezes por ano. No Marrocos, por exemplo, as mudanças ocorrem em março, outubro e também ao redor do Ramadã. As regras podem variar de país para país e, em alguns casos, dentro de um mesmo país. Essas regras são atualizadas de tempos em tempos. Nos Estados Unidos, elas foram atualizadas pela última vez em 2007.


Para permitir que os aplicativos convertam datas e horários de um local com precisão para o horário equivalente em outro local, o Java precisa rastrear todas essas mudanças conhecidas.


Embora não haja uma agência reguladora internacional que governe as mudanças de fuso horário, existe uma compilação colaborativa de dados de fusos horários conhecida como TZ Database ou IANA Time Zone Database. Este banco de dados contém não apenas regras passadas, mas – quando disponíveis – regras para mudanças futuras.


A IANA atualiza seu banco de dados várias vezes por ano, conforme as informações de fuso horário mudam.


Desde 2002, o JRE depende desse banco de dados para a precisão de suas rotinas de conversão de tempo.


A grande maioria dos usuários de Java recebe atualizações das informações de fuso horário de seu JRE como parte das atualizações regulares do Java. No entanto, há dois casos em que isso não é possível:

  • Embora a maioria dos governos anuncie mudanças em suas regras de fuso horário com aviso suficiente para evitar interrupções, às vezes as alterações nas regras de fuso horário não são anunciadas a tempo para que uma nova versão do banco de dados da IANA seja incluída em uma atualização do JRE antes que a mudança entre em vigor.
  • Em alguns casos, é preferível atualizar apenas as informações de fuso horário, sem alterar o JRE.

Para ambos os casos, a Oracle fornece uma ferramenta chamada TZUpdater.


Como funciona o TZUpdater 2.0

A partir do TZUpdater 2.0, a ferramenta contata os servidores da IANA diretamente e baixa as informações de fuso horário mais atualizadas. Com essa nova funcionalidade, os administradores podem usar a mesma ferramenta para todas as atualizações de informações de fuso horário do JRE.


Para garantir que o Time Zone Database baixado não tenha sido danificado durante o trânsito, a ferramenta o compara com uma soma de verificação conhecida.


O arquivo README contém instruções sobre como usar a ferramenta baixando o banco de dados de fuso horário da IANA para um diretório local, para os casos em que o computador que precisa ser atualizado não consegue acessar os servidores da IANA diretamente.


🔧 Nota importante

Esta ferramenta atualiza apenas as informações de fuso horário no JRE. A maioria dos sistemas operacionais modernos atualizará suas próprias informações de fuso horário como parte de suas atualizações regulares.


❓ Perguntas Frequentes

Em quais versões de JRE/JDK esta ferramenta funciona?

O TZUpdater 2.0 funciona com as versões do JRE/JDK da Oracle 5.0 (1.5) e superiores. Para versões do Java fornecidas por outros fornecedores, entre em contato com o fornecedor.

Meu país/cidade/região está prestes a passar por uma mudança nas regras do horário de verão. Quando uma nova versão da ferramenta com as novas regras estará disponível?

Visite http://www.iana.org/time-zones e siga as instruções em Submission/Discussions para solicitar atualizações do Time Zone Database. Uma vez que uma atualização do Banco de Dados da IANA esteja disponível, você pode usar o TZUpdater 2.0 para aplicar as mudanças.

Qual versão do banco de dados de fuso horário está no JRE versão <xyz>?

Você pode encontrar qual versão do banco de dados da IANA foi originalmente incluída em um JRE específico nesta página: http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html

A Oracle continuará lançando novas versões do TZUpdater?

A ferramenta TZUpdater 2.0 pode baixar atualizações diretamente da IANA. As atualizações ainda podem ser fornecidas como parte da manutenção regular de software.


📚 Para saber mais

Timezones, Daylight Savings, and the TZupdater for the Java Runtime Environment (JRE)
http://www.oracle.com/technetwork/java/javase/timezones-137583.html

🤔 Entendendo o Server JRE: a opção otimizada para servidores

🤔 Entendendo o Server JRE

A página de download do Java SE oferece downloads do Java Runtime Environment (JRE), do Server JRE e do Java Development Kit (JDK).


O JRE é usado para executar uma ampla variedade de programas Java, incluindo aplicações Java em desktops. O JDK é para desenvolvedores Java. Ele contém um JRE completo, conforme descrito acima, e as ferramentas necessárias para criar programas Java, assinar código, gerar documentação, etc. O JDK também inclui várias ferramentas destinadas a monitorar e depurar programas.


Então, onde o Server JRE se encaixa? Da perspectiva de aplicações comuns do lado do servidor, o JRE não possui ferramentas de monitoramento e, no caso de aplicações que compilam código-fonte Java em tempo de execução, o javac. Por outro lado, o JDK inclui funcionalidades adicionais que os administradores de sistema podem não precisar em seus sistemas de produção, como o Java Plugin para navegadores web, agentes de atualização automática e ferramentas de desenvolvimento como o javadoc.


🧩 Apresentando o Server JRE

O Server JRE foi projetado para aplicações do lado do servidor, incluindo apenas os recursos comumente necessários do JRE e do JDK. O Server JRE não possui um instalador dedicado: é simplesmente um diretório compactado para facilitar o uso.


❓ O Server JRE funciona para todas as aplicações de servidor?

Não. Se uma aplicação exigir funcionalidades fora das fornecidas no Server JRE, como ferramentas de desenvolvimento adicionais ou JavaFX, então o Server JRE não seria uma escolha adequada para essa aplicação.


🤷 Se o JDK é um superconjunto do Server JRE, por que não usar simplesmente ele?

A remoção de componentes não utilizados diminui a superfície de ataque potencial, e o tamanho menor torna o armazenamento e a implantação mais rápidos e fáceis. Em um sistema Linux x64, o Server JRE 8 tem cerca de 40% do tamanho do JDK 8 completo.


🏢 Meu fornecedor de software afirma que a aplicação precisa do JDK. Posso usar o Server JRE?

Entre em contato com seu fornecedor de software e pergunte se você pode usar o Server JRE em vez do JDK completo. Se você tiver a capacidade de fazer um teste, deveria experimentar. O Server JRE é sempre recomendado quando possível, em vez do JDK, para executar aplicações.


💡 Posso sugerir mudanças para o que é incluído no Server JRE?

Sim. O objetivo do Server JRE é fornecer as ferramentas necessárias para a maioria, mas admitidamente não para todas, as aplicações de servidor. Há uma reavaliação constante sobre quais componentes são incluídos.


Envie seus comentários através dos canais habituais da Comunidade Oracle.

🚀 Uso e Redistribuição do Java SE Mais Rápidos e Fáceis

Introdução

A nuvem mudou a forma como os aplicativos modernos são desenvolvidos, implantados e consumidos. No lado do cliente, aplicativos nativos prontos para uso, "mobile-first", e interfaces web HTML5/JS são cada vez mais predominantes. No lado da nuvem, os "aplicativos" estão em transição para microsserviços modulares baseados em contêineres e até mesmo para funções. Os desenvolvedores esperam ciclos de lançamento mais frequentes e licenciamento flexível.

O Java continua sendo uma das plataformas de desenvolvimento e aplicação mais populares do mundo. O modelo de construção, lançamento, licenciamento e distribuição do Java SE tem bem mais de uma década e será renovado para atender às necessidades em mudança impulsionadas pela nuvem para o futuro.


Resumo Executivo

  • 📅 Foi proposta uma cadência de lançamento do Java SE a cada seis meses.
  • ⚙️ Será simplificado o modo como desenvolvedores, clientes e consumidores usam o Java SE.
  • 📦 A partir do JDK 9 GA, há planos de distribuir builds do OpenJDK sob a licença GPL.
  • 🔄 Foi proposto um modelo de lançamento baseado em tempo para o Java SE, em vez do histórico modelo baseado em recursos.
  • 🔓 Recursos comerciais anteriormente exclusivos, como o Java Flight Recorder, serão contribuídos para o OpenJDK.
  • 🏗️ Trabalho conjunto com outros contribuidores do OpenJDK para tornar a infraestrutura da comunidade completa, moderna e acessível.
  • 💼 O Oracle JDK continuará como uma oferta comercial de suporte de longo prazo (LTS).
  • 🎯 O Oracle JDK será principalmente para clientes comerciais e de suporte assim que os binários do OpenJDK forem intercambiáveis com o Oracle JDK (previsão para o final de 2018).
  • 📦 Continuarão os aprimoramentos na empacotamento e distribuição de aplicativos completos prontos para execução.

Introdução aos builds do OpenJDK sob a GPL da Oracle

Há planos de distribuir builds do OpenJDK para facilitar a implantação de aplicações Java em ambientes de nuvem pelos desenvolvedores. Inicialmente serão oferecidos binários para Linux x64, com adição de macOS e Windows posteriormente. Estes serão licenciados sob a GPLv2 com a "Classpath Exception", permitindo que os desenvolvedores os distribuam de forma fácil e gratuita com seus frameworks e aplicações.

Recursos comerciais, como o Java Flight Recorder, anteriormente disponíveis apenas no Oracle JDK, também serão disponibilizados como código aberto. Há planos de abrir o código de vários projetos internos de desenvolvimento adicionais, após discussão com os contribuidores do OpenJDK.

Embora se saiba que inicialmente haverá diferenças, a intenção é que dentro de alguns lançamentos não haja diferenças técnicas entre os builds do OpenJDK e os binários do Oracle JDK. Para alcançar isso, será realizado um trabalho conjunto com outros contribuidores do OpenJDK em uma infraestrutura aberta de build e teste com potencial para suportar portes adicionais.


Suporte Contínuo do Oracle JDK

O Oracle JDK continuará sendo construído e distribuído. O Oracle JDK 8 continuará recebendo atualizações públicas por pelo menos mais um ano, e o suporte comercial estará disponível até 2025. À medida que os binários do OpenJDK se tornarem o canal principal para os desenvolvedores acessarem as últimas inovações na plataforma Java SE, o Oracle JDK permanecerá como uma oferta de suporte de longo prazo (LTS) para os clientes comerciais e de suporte da Oracle.

Recursos comerciais empacotados separadamente do Oracle JDK, como o Advanced Management Console, continuarão a ser fornecidos separadamente por meio da oferta comercial "Java SE Advanced" da Oracle.

Como o desenvolvimento de aplicativos cliente continua a migrar do antigo mundo do "plugin" para a implantação moderna, a necessidade de um Java Runtime Environment (JRE) independente, instalado centralmente e separado dos aplicativos Java, diminuiu. Usar a ferramenta 'jlink', introduzida com o JDK 9, tornará ainda mais fácil para os desenvolvedores de aplicativos empacotar e implantar runtimes dedicados, em vez de depender de um JRE de sistema pré-instalado. Haverá início da transição da arquitetura autônoma mais tarde no próximo ano, em um esforço que levará vários anos.

sexta-feira, 11 de junho de 2021

🌍 Nosso Mundo. Movido por Java.

🌍 Nosso Mundo. Movido por Java.


Uma Jornada de 25 Anos

É difícil acreditar que já se passaram 25 anos desde que o Java se tornou oficialmente disponível. Por outro lado, parece que várias eras se passaram – e, de certo modo, passaram mesmo.


O Início de Uma Missão

Mesmo sendo um grupo pequeno, a equipe pensava grande. Havia tantas empresas e pessoas que acreditavam na perspectiva de "escreva uma vez, execute em qualquer lugar" que o desafio não era como cobrir todo o hardware e sistemas operacionais diferentes, mas sim como canalizar, focar e organizar os esforços de tantas partes que queriam... participar da festa!

Felizmente isso aconteceu – e elas participaram. E agora, 25 anos depois, é uma alegria celebrar "o primeiro quarto de século do Java".


Uma Visão Superada

Hoje, aquela visão original, por mais ambiciosa que fosse, foi alcançada e superada muitas vezes, conforme o Java evoluiu para ajudar os desenvolvedores a enfrentar novos desafios. A indústria de software abraçou o Java porque ele tornou o desenvolvimento um prazer, resolveu problemas de distribuição e eliminou a dor de portar constantemente entre plataformas.

O Java foi aproveitado pelo universo crescente de websites e fez o conteúdo estático ganhar vida, não apenas com coisas divertidas como o Duke quicando, mas também com uso real para a distribuição de aplicativos de negócios.

A utilidade do Java se multiplicou quando as pessoas perceberam como ele poderia resolver seus problemas em servidores – elevando a produtividade, o desempenho e a escalabilidade a novos patamares. Da distribuição de software pela internet à escalabilidade do lado do servidor da arquitetura multicamada, do aproveitamento de arquiteturas de hardware em constante melhoria às implantações nativas em nuvem, e muito mais.


Constância na Mudança

Durante todo esse tempo, aqueles que escolheram apostar no Java foram recompensados com uma tecnologia que evoluiu continuamente para apoiá-los. Através de mudanças constantes na indústria, o Java forneceu uma batida constante de estabilidade, compatibilidade e um ecossistema cada vez maior de ferramentas, bibliotecas e frameworks para escolher.


Uma Visão que Permanece

A visão é a mesma hoje como era então – uma busca incessante pela produtividade do desenvolvedor e pelo desempenho do programa, mantendo a legibilidade e a compatibilidade diante de um cenário tecnológico em constante evolução.


Celebrando o Presente e o Futuro

Para marcar o 25º aniversário do Java, está sendo usado o tema "Nosso Mundo. Movido por Java." Esta celebração tem como objetivo honrar o passado, reconhecer o presente e oferecer um vislumbre do futuro... bem como agradecer às muitas vozes influentes na comunidade Java.

Conforme o Java nos leva adiante através dos avanços tecnológicos, um conjunto diversificado de programas comunitários destacará inovadores, inovações e organizações que movem o mundo com Java. Desde empresas que constroem aplicativos dos quais dependemos todos os dias, até professores que transmitem o ofício da programação para a próxima geração de desenvolvedores, e alunos que carregarão a tocha por muitos anos vindouros. E através de tudo isso, será compartilhada a contínua liderança tecnológica e a administração comunitária que estão impulsionando a inovação e evolução contínuas do Java.

Há um convite para participar do webcast online inaugural que acontecerá em 20 de maio, onde muitos rostos técnicos e comunitários reconhecidos compartilharão suas memórias e insights sobre o Java.

Além disso, como uma oferta especial, a Oracle University está oferecendo o exame de certificação Java por apenas US$ 25. Esta oferta especial é válida até 25 de abril de 2021.


Seguindo em Frente

25 anos? Sim, tem sido uma jornada incrível, mas é uma jornada que continua avançando. Vamos manter o mundo avançando e tornar os próximos 25 anos ainda melhores... JUNTOS!

Nosso Mundo. Movido por Java.

💻 Java e a Nova Personalidade do Duke: Conheça o Duke Surfista da Nuvem!

Java e a Nova Personalidade do Duke

Por mais de 24 anos, a tecnologia Java tem avançado o mundo com o qual interagimos todos os dias. Com a gestão da Oracle, a tecnologia Java continua a oferecer aos desenvolvedores funcionalidades inovadoras para construir a próxima geração de aplicações que trazem utilidade para nós, tanto pessoal quanto profissionalmente.


E durante a história do Java, ela foi representada pela personalidade altamente reconhecida do Duke. Nos primeiros dias do desenvolvimento Java, a equipe do Projeto Green da Sun Microsystems criou sua primeira demonstração funcional — um controlador interativo de entretenimento doméstico portátil chamado Star7. No coração da interface de usuário animada de tela sensível ao toque estava um personagem de desenho animado chamado Duke.


O Duke saltitante e dando cambalhotas foi criado por um dos artistas gráficos da equipe. Ele seguiu para trabalhar em filmes animados populares como Shrek, Sobre Rodas e A Casa Monstro.


O Duke foi projetado para representar um "agente de software" que realizava tarefas para o usuário. Duke era o anfitrião interativo que permitia um novo tipo de interface de usuário que ia além dos botões, mouses e menus pop-up do mundo da computação desktop.


O Duke foi instantaneamente adotado. Na verdade, quase ao mesmo tempo em que o Java foi introduzido e o primeiro logo da xícara de Java foi encomendado, o Duke se tornou o mascote oficial da tecnologia Java. Em 2006, o Duke foi oficialmente "aberto" sob uma licença BSD. Desenvolvedores e designers foram incentivados a experimentar com o Duke e, pela primeira vez, tiveram acesso às especificações gráficas do Duke por meio de um projeto no java.net. Os esforços em torno do Duke agora são hospedados como "Project Duke" no OpenJDK.


Na Oracle, o Duke também é celebrado. Um Duke em tamanho real foi uma atração popular em todas as conferências de desenvolvedores JavaOne, e agora no principal evento de desenvolvedores da Oracle... o Oracle Code One.


🎉 Dando as Boas-Vindas ao Duke Surfista da Nuvem!

Este ano, a Oracle está lançando uma nova personalidade para o Duke que incorpora o espírito aberto e inovador e como o Java continua a se projetar para o futuro. Ajude a dar as boas-vindas ao Duke Surfista da Nuvem!