AWS Lambda agora suporta Java 25

Por Lefteris Karageorgiou, Arquiteto de Soluções Sênior na Amazon Web Services e Julian Wood, Principal Developer Advocate na Amazon Web Services.

Agora você pode desenvolver funções AWS Lambda usando Java 25 como um runtime gerenciado ou usando a imagem base de container. O suporte ao Java 25 para Lambda é baseado na distribuição Amazon Corretto do OpenJDK e agora está disponível de forma geral.

Java 25 vem com novos recursos de linguagem para desenvolvedores, incluindo tipos primitivos em padrões, declarações de importação de módulo e corpos de construtor flexíveis, bem como suporte geracional ao coletor de lixo Shenandoah. Há mudanças no runtime do Lambda para otimizar Cold starts usando o novo recurso de caches Ahead-of-Time (AOT) do Java. Esta versão também inclui atualizações na compilação em camadas padrão para SnapStart e Provisioned Concurrency, e remove o patch Log4Shell. Com esta versão, desenvolvedores Java podem aproveitar esses novos recursos e melhorias ao criar aplicações Serverless no Lambda.

Você pode desenvolver funções Lambda em Java 25 usando o AWS Management Console, AWS Command Line Interface (AWS CLI), AWS SDK for JavaScript, AWS Serverless Application Model (AWS SAM), AWS Cloud Development Kit (AWS CDK), e outras ferramentas de infraestrutura como código. Você também pode usar Java 25 com Powertools for AWS Lambda (Java), um kit de ferramentas para desenvolvedores para implementar melhores práticas Serverless e aumentar a velocidade de desenvolvimento. Powertools for AWS Lambda inclui bibliotecas para suportar tarefas comuns como observabilidade, integração com AWS Systems Manager Parameter Store, idempotência, processamento em lote, e muito mais.

Esta publicação destaca recursos notáveis da linguagem Java, atualizações do runtime Java do Lambda e como você pode usar o novo runtime Java 25 em suas aplicações Serverless.

Recursos da linguagem Java 25

Java 25 introduz vários recursos de linguagem para aumentar a produtividade do desenvolvedor. Há um novo recurso que permite que instruções apareçam antes de uma invocação explícita de construtor. Agora você pode escrever código nos construtores sem ter que invocar super(…) ou this(…) como a primeira instrução. No exemplo a seguir, a classe Employee tem um construtor que valida a entrada primeiro e depois invoca super(…):


class Person {
    int age;

    Person(int age) {
        if (age < 0)
            throw new IllegalArgumentException("Age cannot be negative");

        this.age = age;
    }
}

class Employee extends Person {
    String name;

    Employee(String name, int age) {
        // This is now allowed - code before super()
        if (age < 18 || age > 67)
            throw new IllegalArgumentException(...);

        super(age);
        this.name = name;
    }
}

Java 25 suporta correspondência de padrões que pode lidar com tipos primitivos em instruções switch e instanceof. Anteriormente, a correspondência de padrões era limitada a tipos de referência (Objects). Por exemplo, agora você pode realizar correspondência de padrões com valores int, não apenas objetos Integer:

void primitivePatternMatching(Object obj) {
    if (obj instanceof int i) {
        System.out.println("This is an int: " + i);
    }
}

Declarações de importação de módulo simplificam o trabalho com. Em vez de escrever múltiplas importações de pacotes individuais do mesmo módulo, você pode usar a sintaxe import para trazer tipos exportados publicamente para o escopo. Isso reduz código boilerplate e facilita o trabalho com aplicações modulares. Anteriormente, se você usasse o módulo java.net.http, você tinha que importar múltiplas classes com instruções de importação individuais:

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;

public class HttpClientExample {
    public void makeRequest() {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("https://api.example.com"))
            .build();
        // ... rest of implementation
    }
}

Agora você pode importar todo o módulo java.net.http:

import module java.net.http;

public class HttpClientExample {
    public void makeRequest() {
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("https://api.example.com"))
            .build();
        // Exported types from java.net.http module are now available
    }
}

Garbage collection

O modo geracional do garbage collector Shenandoah muda de um recurso experimental no Java 24 para um recurso de produto opcional. Shenandoah é o garbage collector de baixo tempo de pausa que reduz os tempos de pausa realizando mais trabalho de coleta de lixo simultaneamente com o programa Java em execução. Shenandoah faz a maior parte do trabalho de GC simultaneamente, incluindo a compactação simultânea, o que significa que seus tempos de pausa não são mais diretamente proporcionais ao tamanho do heap. O modo geracional do Shenandoah melhora o throughput sustentável, resiliência a picos de carga e utilização de memória.

Para usar o modelo geracional do Shenandoah no Lambda, defina JAVA_TOOL_OPTIONS como -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational.

Atualizações do runtime do Lambda

O runtime Java 25 inclui várias otimizações de desempenho, ajustadas para otimizar o desempenho de Cold start e Warm start para uma ampla gama de cargas de trabalho de clientes. Cold start refere-se ao atraso de inicialização que ocorre quando o Lambda prepara um novo ambiente de execução para uma função que não foi invocada recentemente, ou para processar uma invocação quando todos os ambientes de execução existentes estão em uso. Warm start refere-se a invocações que são alocadas a um ambiente de execução previamente inicializado.

Caches Ahead-of-Time (AOT)

A partir do Java 25, o AWS Lambda substitui o tradicional Class Data Sharing (CDS) por caches ahead-of-time (AOT). Este é um recurso avançado de otimização do Project Leyden que foi projetado para melhorar os tempos de inicialização de aplicações e reduzir a pegada de memória. Os resultados de benchmarking do Lambda mostram que os caches AOT oferecem desempenho de Cold start mais rápido em comparação com CDS.

Os caches AOT são habilitados por padrão para fornecer benefícios de desempenho. Como você não pode usar tanto caches AOT quanto CDS, se você habilitar CDS em sua função Lambda, então o Lambda desabilita os caches AOT. Se você usar seus próprios caches AOT personalizados no runtime gerenciado Java 25, então os caches podem ser invalidados quando o Lambda atualiza o runtime Java durante patches de rotina. A AWS recomenda fortemente que você não use caches AOT personalizados com runtimes gerenciados.

Se você implantar funções Java 25 usando imagens de container, você pode implementar seus próprios caches AOT ou continuar usando CDS. Como as imagens de container são imutáveis, o problema de caches AOT sendo invalidados após patches automáticos de runtime não ocorre. Para habilitar caches AOT, passe a flag -XX:AOTCache=/path/to/aot/cache/file através da variável de ambiente JAVA_TOOL_OPTIONS. Para habilitar CDS, passe a flag -Xshare:on -XX:SharedArchiveFile=/var/lang/lib/server/runtime.jsa.

Compilação em camadas

A compilação em camadas do Java é uma estratégia de otimização just-in-time (JIT) que emprega múltiplas camadas de compilador para melhorar progressivamente o desempenho de código executado com frequência usando dados de perfil de runtime. Desde o Java 17, o AWS Lambda modificou o comportamento padrão da JVM parando a compilação na camada C1 (compilador cliente). Isso minimiza os tempos de Cold start para invocações de função para a maioria das funções, embora para funções intensivas em computação com longa duração, os clientes possam se beneficiar do ajuste da compilação em camadas para sua carga de trabalho. A partir do Java 25, o Lambda não para mais a compilação em camadas em C1 para SnapStart e Provisioned Concurrency. Isso melhora o desempenho nesses casos sem incorrer em uma penalidade de Cold start, já que a compilação em camadas ocorre fora do caminho de invocação nesses casos.

Priming

Priming é outra técnica para otimizar o desempenho de funções usando SnapStart ou Provisioned Concurrency. Isso envolve pré-carregar dependências, inicializar recursos e executar caminhos de código durante a inicialização da função. Isso antecipa o trabalho e aciona a compilação JIT antes de tirar o snapshot do SnapStart, ou quando os ambientes de execução do Provisioned Concurrency são pré-provisionados. O resultado é uma execução de código mais rápida quando esses ambientes de execução são usados para uma invocação warm da função. Para orientação detalhada sobre implementação de estratégias de priming, consulte o post do blog Otimizando o desempenho de Cold start do AWS Lambda usando estratégias avançadas de priming com SnapStart.

Patch Log4j para Log4Shell

Log4j é uma biblioteca de logging de código aberto amplamente usada mantida pela Apache Software Foundation. Em novembro de 2021, o Log4j relatou Log4Shell, uma vulnerabilidade de dia zero envolvendo execução arbitrária de código. A equipe do Lambda respondeu implantando um patch de emergência em todos os runtimes Java para proteger os clientes de potencial exploração. No entanto, este patch de emergência introduziu uma sobrecarga de desempenho durante Cold starts. A vulnerabilidade foi permanentemente resolvida no Log4j versão 2.17.0 em dezembro de 2021. Consequentemente, a AWS removeu este patch do runtime Java 25 para restaurar o desempenho ideal. Você deve verificar se está usando o Log4j versão 2.17.0 ou posterior.

Os runtimes do Lambda para Java 8, 11, 17 e 21 continuam a habilitar o patch de emergência por padrão. Clientes que estão usando o Log4j versão 2.17.0 ou superior com esses runtimes podem desabilitar este patch, melhorando o desempenho de Cold start. Para desabilitar o patch, defina a variável de ambiente AWS_LAMBDA_DISABLE_CVE_2021_44228_PROTECTION como true.

Considerações adicionais de desempenho

No lançamento, novos runtimes do Lambda recebem menos uso do que runtimes existentes e estabelecidos. Isso pode resultar em tempos de Cold start mais longos devido à residência de cache reduzida dentro dos subsistemas internos do Lambda. Os tempos de Cold start normalmente melhoram nas semanas seguintes ao lançamento à medida que o uso aumenta. Como resultado, a AWS recomenda não tirar conclusões de comparações de desempenho lado a lado com outros runtimes do Lambda até que o desempenho tenha se estabilizado.

Como o desempenho é altamente dependente da carga de trabalho, clientes com cargas de trabalho sensíveis ao desempenho devem conduzir seus próprios testes em vez de confiar em benchmarks de teste genéricos. Para maximizar o desempenho, sua carga de trabalho pode se beneficiar de ajuste de desempenho adicional específico da carga de trabalho.

Usando Java 25 no AWS Lambda

Você pode usar Java 25 para suas funções Lambda no AWS Management Console, uma imagem de container do AWS Lambda, AWS SAM ou AWS CDK.

AWS Management Console

Para usar o runtime Java 25 para desenvolver suas funções Lambda, especifique um valor de parâmetro de runtime Java 25 ao criar ou atualizar uma função. A versão do runtime Java 25 agora está disponível no menu suspenso Runtime na página Create function no console do AWS Lambda:

Criando função Java 25 no AWS Management Console

Para atualizar uma função Lambda existente para Java 25, navegue até a função no console do Lambda, depois escolha Java 25 na seção Runtime settings. A nova versão está disponível no menu suspenso Runtime:

Alterando uma função para Java 25

Imagem de container do AWS Lambda

Use a versão da imagem base Java com a tag java:25 modificando a instrução FROM no seu Dockerfile.

Exemplo de Dockerfile:

FROM public.ecr.aws/lambda/java:25
# Copy function code and runtime dependencies from Maven layout
COPY target/classes ${LAMBDA_TASK_ROOT}
COPY target/dependency/* ${LAMBDA_TASK_ROOT}/lib/
# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "com.example.myapp.App::handleRequest" ]

Para construir uma imagem de container para uma função Lambda Java, consulte a documentação do AWS Lambda.

AWS Serverless Application Model (AWS SAM)

No AWS SAM, defina o atributo Runtime como java25 para usar esta versão:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Simple Lambda Function

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: HelloWorldFunction
      Handler: helloworld.App::handleRequest
      Runtime: java25
      MemorySize: 1024

O AWS SAM suporta a geração deste template com Java 25 para novas aplicações Serverless usando o comando sam init. Consulte a documentação do AWS SAM.

AWS Cloud Development Kit (AWS CDK)

No AWS CDK, defina o atributo runtime como Runtime.JAVA_25 para usar esta versão.

import software.amazon.awscdk.core.Construct;
import software.amazon.awscdk.core.Stack;
import software.amazon.awscdk.core.StackProps;
import software.amazon.awscdk.services.lambda.Code;
import software.amazon.awscdk.services.lambda.Function;
import software.amazon.awscdk.services.lambda.Runtime;

public class InfrastructureStack extends Stack {

    public InfrastructureStack(final Construct parent, final String id, final StackProps props) {

        super(parent, id, props);

        Function.Builder.create(this, "HelloWorldFunction")
                .runtime(Runtime.JAVA_25)
                .code(Code.fromAsset("target/hello-world.jar"))
                .handler("helloworld.App::handleRequest")
                .memorySize(1024)
                .build();

        // rest of your CDK code
    }
}

Conclusão

O Lambda agora suporta Java 25 como um runtime de linguagem gerenciado ou com seu próprio runtime personalizado. Esta versão inclui os recursos mais recentes da linguagem Java 25, bem como melhorias de desempenho otimizadas para cargas de trabalho do Lambda.

Você pode construir e implantar funções usando Java 25 usando o AWS Management Console, AWS CLI, AWS SDK, AWS SAM, AWS CDK, ou sua escolha de ferramenta de infraestrutura como código. Você também pode usar a imagem base de container Java com a tag 25 se preferir construir e implantar suas funções usando imagens de container.

O runtime Java 25 ajuda desenvolvedores a construir aplicações Serverless mais eficientes, poderosas e escaláveis. Leia sobre o modelo de programação Java na documentação do Lambda para aprender mais sobre como escrever funções em Java 25.

Para encontrar mais exemplos em Java, use a Coleção de Padrões Serverless. Para mais recursos de aprendizado Serverless, visite Serverless Land.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

	Lefteris Karageorgiou é um Arquiteto de Soluções Sênior na Amazon Web Services.
	Julian Wood é um Principal Developer Advocate na Amazon Web Services.

Tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/

Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.

O blog da AWS