0Pricing
Java Academy · Aula

Por que FFM em vez de JNI

Integração nativa mais segura.

Por que FFM em vez de JNI é uma aula grátis de Java Academy no CoddyKit. Esta é a aula 1 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Java Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Java Academy inclui 4 aulas no total.

Chamando código nativo

Às vezes, Java precisa chamar bibliotecas C ou trabalhar com memória fora da área gerenciada. A forma clássica era a Interface Nativa do Java (JNI). A forma moderna é a API de Funções Estrangeiras e Memória (FFM), finalizada no Java 22 (JEP 454).

Esta lição explica por que FFM é a melhor escolha.

O que JNI exigia

JNI era trabalhoso:

  • Escrever código de ligação em C com assinaturas complicadas JNIEXPORT
  • Compilar uma biblioteca nativa compartilhada para cada plataforma
  • Converter manualmente entre tipos Java e C
  • É fácil causar uma falha na JVM com um erro

FFM é Java puro

FFM permite chamar funções nativas e acessar memória nativa inteiramente a partir de Java. Sem código de ligação em C, sem uma etapa separada de compilação e sem conversão manual entre tipos.

Você descreve a assinatura da função nativa em Java e a invoca por meio de um identificador de método.

Os pacotes principais

Tudo fica em java.lang.foreign. Os tipos principais são:

  • Linker e SymbolLookup para localizar e vincular funções
  • MemorySegment para memória nativa
  • Arena para controlar o tempo de vida de forma determinística
  • MemoryLayout e FunctionDescriptor para descrever formatos

Segurança desde o projeto

FFM é muito mais seguro que JNI:

  • Acesso à memória com verificação de limites
  • Tempo de vida vinculado a uma Arena, portanto o uso após a liberação é detectado
  • O confinamento impede o acesso inseguro entre linhas de execução

Os erros geram exceções Java em vez de provocar o travamento da VM.

Uma amostra da API

Este esboço encontra a função C strlen e prepara um identificador para ela. A ideia é que tudo isso seja código Java comum.

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;

public class Main {
    public static void main(String[] args) {
        Linker linker = Linker.nativeLinker();
        SymbolLookup stdlib = linker.defaultLookup();
        MethodHandle strlen = linker.downcallHandle(
            stdlib.find("strlen").orElseThrow(),
            FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS));
        System.out.println("Bound a handle to strlen: " + strlen);
    }
}

Desempenho

As chamadas descendentes FFM têm desempenho comparável ao JNI e muitas vezes são mais rápidas, pois o compilador JIT pode inserir e otimizar as pontes geradas. Não há um trampolim C por chamada para atravessar.

Habilitando o acesso nativo

Como o código nativo pode ser perigoso, FFM pode emitir um aviso ou exigir uma habilitação explícita. O acesso é concedido na inicialização com --enable-native-access=ALL-UNNAMED (ou com um nome de módulo específico) para silenciar os avisos.

Substituindo sun.misc.Unsafe

FFM (com a API de Memória) também é a substituição oficialmente recomendada para as operações de memória fora da área gerenciada de sun.misc.Unsafe, obsoletas há muito tempo. Bibliotecas que gerenciavam buffers nativos manualmente podem migrar para APIs seguras e compatíveis.

Ferramenta: jextract

Para bibliotecas C grandes, a ferramenta complementar jextract lê um arquivo de cabeçalho C e gera automaticamente as vinculações FFM para Java. Você não precisa escrever as descrições manualmente.

Ela é a contraparte voltada à produtividade do FFM, muito semelhante a um gerador de código.

Quando usar FFM

Use FFM quando for necessário:

  • Chamar uma biblioteca C/C++ existente
  • Interoperar com o sistema operacional em baixo nível
  • Gerenciar buffers nativos grandes com eficiência

Para trabalhos exclusivamente em Java, você nunca precisa dele.

Verificação rápida

Lembre-se da principal vantagem sobre JNI.

Recapitulação

Você aprendeu por que FFM é melhor que JNI:

  • Java puro, sem código de ligação C nem compilação adicional
  • Seguro: verificação de limites, tempos de vida controlados por Arena e confinamento
  • Desempenho comparável ou superior
  • Substitui sun.misc.Unsafe e combina com jextract

A seguir: gerenciamento de memória nativa com MemorySegment e Arena.

Perguntas Frequentes

A aula “Por que FFM em vez de JNI” é grátis?

Sim — o texto completo de “Por que FFM em vez de JNI” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Java Academy, atualize para CoddyKit PRO. O curso de Java Academy inclui 4 aulas no total.

O que vou aprender em “Por que FFM em vez de JNI”?

Integração nativa mais segura. Você pratica Java Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Java Academy?

Nenhuma experiência prévia é necessária. Java Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 1 de 4.

Quanto tempo leva a aula “Por que FFM em vez de JNI”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Java Academy?

Sim. Cada aula de Java Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Por que FFM em vez de JNI
  2. MemorySegment e Arena
  3. Handles de downcall
  4. Layouts e structs
← Voltar para Java Academy