DEV Community: Java Efetivo (livro)

Despedida e Links

Java Efetivo (livro) — Thu, 13 Feb 2025 14:55:58 +0000

Agradecemos imensamente a todes que estiveram conosco nessa jornada de estudos.

Link da Playlist em Videos do Grupo de Estudos Java Efetivo:
https://youtube.com/playlist?list=PLAa4y8yJfr91RNSgHWliOsZkAU1_hNxim&si=gyQlX6EH5GTMv4xH

Outros Links:

YouTube da Comunidade:
https://www.youtube.com/@javagirlsjug

Playlists:
Java para Iniciantes 1:
https://youtube.com/playlist?list=PLAa4y8yJfr92nHJAXS5Y2n-m7Nu5yHA5T&si=NCoC58Lc-q-HUJeG

Java para Iniciantes 2:
https://youtube.com/playlist?list=PLAa4y8yJfr91CNAKBNfV0HMBETn2oWbmD&si=I4s8xMWZgr9nhdbX

Links dos Resuminhos em Blogs no Dev.to:
https://dev.to/javaparainiciantes
https://dev.to/javaefetivo
https://dev.to/psanrosa13

Site da comunidade:
https://javagirlsjug.org

Serialização em Java na atualidade e novas abordagens em 2025

Java Efetivo (livro) — Thu, 13 Feb 2025 14:45:48 +0000

O padrão de proxy de serialização (recomendada pelo livro) ainda é uma solução válida e segura no Java, especialmente para classes com invariantes complexas ou que exigem imutabilidade real. No entanto, com as evoluções da linguagem e das práticas de desenvolvimento, há abordagens mais modernas e recomendadas para muitos cenários.

Abordagens mais modernas para segurança na serialização e desserialização

1- Evitar completamente a serialização nativa do Java (Serializable)

O próprio criador do Java (Joshua Bloch) recomenda evitar Serializable devido aos riscos de segurança e complexidade.
Em vez disso, é melhor utilizar formatos de serialização mais seguros, como JSON, XML ou Protobuf, que oferecem mais controle sobre o que está sendo serializado.

Alternativas:

Usar Jackson (com.fasterxml.jackson.databind) para JSON.
Utilizar Protocol Buffers (protobuf) / Apache Avro para uma serialização mais eficiente e segura.

Links:
https://www.linkedin.com/pulse/o-linkedin-substituiu-json-por-protobuf-e-conseguiu-uma-deschamps-s2jkf/

2- Uso de classes imutáveis e transient

Objetos imutáveis são naturalmente mais seguros para serialização.

Usar Classes Imutáveis Modernas
Substitua tipos mutáveis (ex.: Date, ArrayList) por classes imutáveis do java.time (LocalDate, Instant) ou coleções imutáveis (List.of(), Set.copyOf()).

Records (Java 16+):

public record Period(LocalDate start, LocalDate end) { 
    // Validação no construtor compacto
    public Period {
        if (end.isBefore(start)) throw new IllegalArgumentException();
    }
}

Simplifica a criação de classes imutáveis e elimina a necessidade de cópias defensivas.

Marcar campos sensíveis como transient impede que sejam serializados.

Exemplo:

public final class SecureData implements Serializable {
    private static final long serialVersionUID = 1L;

    private final String publicData;
    private transient String sensitiveData; // Não será serializado

    public SecureData(String publicData, String sensitiveData) {
        this.publicData = publicData;
        this.sensitiveData = sensitiveData;
    }
}

3- ObjectInputFilter (Desde Java 9)

Java 9 introduziu o ObjectInputFilter, que permite definir filtros de segurança para impedir ataques de desserialização de objetos inesperados ou perigosos.

Exemplo:

ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
    "com.meusistema.SeguraClass;!*"
);
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("data.ser"));
ois.setObjectInputFilter(filter);

Benefício: Permite controlar quais classes podem ser desserializadas.

4- Biblioteca Kryo (Mais segura e rápida)

Kryo é uma alternativa moderna e eficiente para serialização, sendo mais rápida e mais segura que a serialização padrão do Java.

Kryo kryo = new Kryo();
Output output = new Output(new FileOutputStream("data.bin"));
kryo.writeObject(output, myObject);
output.close();

Leitura:
https://medium.com/@prekshaan95/kryo-serialization-and-deserialization-in-java-9e6da25e2a76

Benefício: Melhor desempenho e segurança, usado em frameworks como Akka.

5- Serialização Customizada com writeObject() e readObject()

private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
    throw new InvalidObjectException("Desserialização não permitida!");
}

Benefício: Bloqueia ataques de desserialização.

6- Serialização com Frameworks Seguros
Spring Boot / Micronaut / Quarkus:

Frameworks modernos evitam a serialização nativa do Java, preferindo JSON via REST APIs.
Usam DTOs (Data Transfer Objects) imutáveis para transferência segura de dados.

7- Padrão de Serialização Baseada em Construtores
Em vez de depender de proxies, use construtores ou factories para reconstruir objetos após a desserialização:

public class Period implements Serializable {
    private final LocalDate start;
    private final LocalDate end;

    // Construtor público com validação
    public Period(LocalDate start, LocalDate end) {
        if (end.isBefore(start)) throw new IllegalArgumentException();
        this.start = start;
        this.end = end;
    }

    private Object readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
        ois.defaultReadObject();
        return new Period(start, end); // Reconstrução segura
    }
}

Quando o Proxy de Serialização Ainda é Útil?

Cenários críticos: Sistemas financeiros, APIs de segurança, onde a validação rigorosa é essencial.
Legado: Projetos que não podem migrar para formatos modernos (ex.: sistemas embarcados, aplicações empresariais antigas).

Comparativo: Proxy vs. Alternativas Modernas

Conclusão: Qual abordagem usar?

Se a segurança for crítica, evite Serializable e use JSON ou Protobuf. Se ainda precisar usar Serializable, aplique ObjectInputFilter e classes imutáveis.

Item 90: Pense em usar proxies de serialização em vez de instâncias serializadas

Java Efetivo (livro) — Wed, 12 Feb 2025 23:42:34 +0000

Atenção: Com as evoluções do Java e práticas modernas, existem alternativas mais seguras e eficientes para lidar com serialização/desserialização. Mas como estamos estudando o livro vamos considerar para aprender. VER NO TÓPICO FINAL SOBRE SERIALIZAÇÃO

Resumo do Item 90: Use Proxies de Serialização em vez de Instâncias Serializadas

Problemas da Serialização Direta
Riscos de segurança e bugs:

Permite criar objetos sem passar por construtores normais.
Violação de invariantes: Desserialização pode gerar instâncias inválidas.
Ataques maliciosos: Streams de bytes manipuladas podem explorar vulnerabilidades.

O que é o Padrão de Proxy de Serialização?
Objetivo: Substituir a serialização nativa por uma abordagem segura e controlada.

Funcionamento:

Cria uma classe proxy aninhada (serializável) que encapsula o estado da classe principal.
Garante que apenas o proxy é serializado/desserializado, não a classe original.

Implementação do Proxy de Serialização

Criar a classe proxy:

Classe estática privada, serializável, com campos idênticos à classe principal.
Construtor recebe a instância original e copia seus dados.

private static class SerializationProxy implements Serializable {
    private final Date start;
    private final Date end;

    SerializationProxy(Period p) {
        this.start = p.start;
        this.end = p.end;
    }
}

Método writeReplace na classe principal:
Substitui a instância original pelo proxy durante a serialização.

private Object writeReplace() {
    return new SerializationProxy(this);
}

Bloquear desserialização direta:
Adicionar readObject que lança exceção para evitar bypass do proxy.

private void readObject(ObjectInputStream ois) throws InvalidObjectException {
    throw new InvalidObjectException("Use o proxy!");
}

Método readResolve no proxy:
Converte o proxy de volta em uma instância válida da classe principal.

private Object readResolve() {
    return new Period(start, end); // Usa o construtor público
}

Vantagens do Padrão

Segurança reforçada:

Elimina riscos de streams maliciosas e exposição de campos privados.
Preserva imutabilidade: Campos final são mantidos sem restrições.

Flexibilidade:

Permite alterar a implementação interna da classe sem quebrar compatibilidade (ex.: EnumSet).
Simplicidade: Mais fácil de validar do que cópias defensivas.

Limitações

Classes extensíveis: Não funciona bem se a classe pode ser herdada por usuários (viola encapsulamento).
Grafos circulares: Pode causar ClassCastException em objetos com referências cíclicas.
Desempenho: ~14% mais lento que serialização padrão (trade-off aceitável para segurança).

Conclusão

Use proxies de serialização sempre que:
A classe tem invariantes complexas.
A segurança é crítica (ex.: dados sensíveis).
Quer evitar códigos de validação/cópia defensiva manuais.
Priorize este padrão sobre readObject/writeObject customizados para garantir robustez e imutabilidade real.

Chave: O proxy assegura que a desserialização sempre passa pelo construtor público, validando invariantes e bloqueando ataques!

Exemplos do Livro:

Resumo - Item 89: Dê preferência aos tipos enum em vez do readResolve para controle de instância

Java Efetivo (livro) — Wed, 12 Feb 2025 23:30:29 +0000

Problema do Singleton e Serialização

Um singleton pode perder sua unicidade se for declarado como Serializable.
A serialização cria uma nova instância ao desserializar, quebrando a restrição do singleton.
O método readResolve pode ser usado para substituir a instância desserializada pela instância original.

Vulnerabilidade do readResolve

Se um singleton tiver campos não transientes, um invasor pode capturar uma referência à instância antes da execução do readResolve.
Isso permite criar múltiplas instâncias do singleton, contornando a restrição de instância única.
O ataque pode ser feito utilizando uma classe "ladra" que explora a desserialização circular para obter uma cópia do singleton antes que ele seja resolvido.

Solução mais segura: Usar enum para Singletons

Enums são implicitamente serializáveis e garantem que só existe uma única instância.
O Java impede a criação de novas instâncias além das constantes declaradas no enum.

Exemplo seguro:

public enum Elvis {
    INSTANCE;
    public void sing() { System.out.println("Love me tender"); }
}

Quando ainda usar readResolve?

Se a classe não pode ser um enum e precisa ser controlada por instância.
Deve garantir que todos os campos de referência sejam transientes.
O readResolve deve ter a acessibilidade adequada (privado em classes final).

Conclusão

Prefira enum para singletons, pois é seguro e simples.
Se precisar usar readResolve, tome precauções para evitar ataques.

Exemplos de códigos do livro:

Resumo do Item 88: Escreva métodos readObject defensivamente

Java Efetivo (livro) — Wed, 12 Feb 2025 23:12:58 +0000

Problema da Desserialização sem Defesa

Uma classe pode ser tornada serializável apenas adicionando implements Serializable, mas isso pode comprometer suas invariantes.
O método readObject age como um construtor público invisível, e precisa das mesmas precauções que um construtor tradicional.
Se não for protegido, um invasor pode criar streams de bytes manipuladas para violar as invariantes da classe.
Exemplo: uma classe Period pode ser manipulada para ter uma data final anterior à inicial.

Ataque por Referência Mutável

Um invasor pode fabricar uma stream de bytes que referencie os objetos mutáveis internos da classe.
Ao modificar esses objetos (ex: Date), o estado da instância serializada pode ser alterado.
Esse tipo de falha compromete a imutabilidade da classe, permitindo modificações após a criação.

Soluções para um readObject Seguro
Cópia defensiva de objetos mutáveis

Sempre copie objetos mutáveis privados ao desserializar (Date, ArrayList, etc.).
Exemplo: em vez de confiar em clone(), crie novas instâncias manualmente.

Verificação de invariantes

Após a cópia, verifique se os valores mantêm as regras da classe.
Se alguma regra for violada, lance uma InvalidObjectException.

Evitar métodos sobrescrevíveis

Durante a desserialização, não chame métodos que possam ser sobrescritos por subclasses.
Isso evita execução de código antes que a classe tenha sido completamente carregada.

Alternativa: Padrão de Proxy de Serialização

Sempre que possível, utilize serialização via proxy (Item 90).
Esse padrão reduz a complexidade e minimiza riscos de falha na desserialização.

Conclusão
Trate readObject como um construtor público: valide e proteja os dados.
Desconfie da stream de bytes: ela pode ter sido manipulada por um invasor.
Sempre copie defensivamente objetos mutáveis para garantir a integridade da classe.

Exemplos de código do livro:

Item 87: Pense na possibilidade de usar uma forma serializada customizada

Java Efetivo (livro) — Thu, 06 Feb 2025 19:50:50 +0000

1. Problema da forma serializada padrão

A forma serializada padrão pode tornar impossível substituir uma implementação descartável.
Muitas classes da biblioteca Java, como BigInteger, sofreram com essa limitação.
Deve-se avaliar se a forma serializada padrão é apropriada em termos de flexibilidade, desempenho e correção.

2. Quando a forma serializada padrão é aceitável?

Quando a representação física do objeto é idêntica ao seu conteúdo lógico.
Exemplo: uma classe Name com três String (sobrenome, primeiro nome e nome do meio).

3. Problemas ao usar a forma serializada padrão quando a representação física difere do conteúdo lógico

Acopla a API pública à implementação interna, impedindo mudanças futuras.
Aumenta o consumo de espaço, armazenando detalhes desnecessários.
Pode ser ineficiente em tempo de execução, devido a percursos desnecessários no grafo do objeto.
Pode causar overflow de pilha, especialmente em listas encadeadas grandes.

4. Exemplo: Serialização de uma lista encadeada (StringList)

A forma serializada padrão armazenaria todos os nós e links internos, o que é ineficiente.
Solução: armazenar apenas o número de elementos e suas String associadas.
Isso reduz o espaço ocupado e melhora a performance da serialização.

5. Implementação de uma forma serializada customizada

Criar os métodos writeObject e readObject para controlar a serialização.
Utilizar o modificador transient para evitar serializar detalhes desnecessários.
Sempre chamar defaultWriteObject e defaultReadObject para garantir compatibilidade futura.
Documentar a API serializada com @serial (campos) e @serialData (métodos).

6. Problema ainda maior com tabelas hash

A posição dos elementos depende do código hash da chave, que pode mudar entre execuções.
Serializar a estrutura física de uma tabela hash poderia corromper suas invariantes.
Solução: armazenar apenas os pares chave-valor e recriar a estrutura na desserialização.

7. Regras gerais para serialização eficiente

Declarar como transient qualquer campo que não faça parte do estado lógico do objeto.
Evitar serializar campos derivados, cujo valor pode ser recalculado.
Evitar serializar ponteiros para estruturas nativas da JVM.

Conclusão

A forma serializada padrão deve ser aceita apenas se for adequada ao estado lógico do objeto.
Para maior controle, use uma forma serializada customizada, garantindo eficiência e flexibilidade.
Isso evita problemas futuros com manutenção, desempenho e compatibilidade da API serializada.

Exemplos do livro:

Exercícios Práticos de Serialização

Java Efetivo (livro) — Thu, 30 Jan 2025 17:42:12 +0000

1.Criar uma classe simples serializável
Implemente Serializable e serialize/deserialize um objeto usando ObjectOutputStream e ObjectInputStream.

2. Testar a compatibilidade de versão
Serializar um objeto de uma versão antiga da classe e tentar desserializá-lo após uma mudança na estrutura da classe.
Testar o comportamento do serialVersionUID.

3. Criar uma forma serializada personalizada
Usar writeObject e readObject para definir manualmente a serialização de uma classe.

4. Explorar riscos de segurança
Criar um objeto vulnerável a ataques via serialização (exemplo: permitir modificação de campos privados via desserialização).
Corrigir a vulnerabilidade implementando readObject.

5. Comparar serialização com outras abordagens
Implementar persistência de um objeto com JSON (Gson, Jackson) e comparar com a serialização Java.

1. Faça uma classe serializável e demonstre a serialização e desserialização de um objeto dessa classe.

import java.io.*;

// Classe serializável
class Pessoa implements Serializable {
    private static final long serialVersionUID = 1L; // UID para manter compatibilidade
    private String nome;
    private int idade;

    public Pessoa(String nome, int idade) {
        this.nome = nome;
        this.idade = idade;
    }

    @Override
    public String toString() {
        return "Pessoa{nome='" + nome + "', idade=" + idade + "}";
    }
}

public class SerializacaoExemplo {
    public static void main(String[] args) {
        Pessoa pessoa = new Pessoa("João", 30);

        // Serializar objeto
        try (ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("pessoa.ser"))) {
            out.writeObject(pessoa);
            System.out.println("Objeto serializado com sucesso!");
        } catch (IOException e) {
            e.printStackTrace();
        }

        // Desserializar objeto
        try (ObjectInputStream in = new ObjectInputStream(new FileInputStream("pessoa.ser"))) {
            Pessoa pessoaLida = (Pessoa) in.readObject();
            System.out.println("Objeto desserializado: " + pessoaLida);
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

📌 Explicação: Esse código cria uma classe Pessoa serializável, salva um objeto em um arquivo e depois o lê de volta.

2. Modifique a classe do exercício anterior para incluir um novo campo e demonstre o problema de compatibilidade ao desserializar um objeto antigo.

import java.io.*;

class Pessoa implements Serializable {
    private static final long serialVersionUID = 1L; // UID fixo para manter compatibilidade
    private String nome;
    private int idade;
    private String email; // Novo campo adicionado

    public Pessoa(String nome, int idade, String email) {
        this.nome = nome;
        this.idade = idade;
        this.email = email;
    }

    @Override
    public String toString() {
        return "Pessoa{nome='" + nome + "', idade=" + idade + ", email='" + email + "'}";
    }
}

public class SerializacaoProblema {
    public static void main(String[] args) {
        // Tentativa de desserializar um objeto criado antes da adição do campo 'email'
        try (ObjectInputStream in = new ObjectInputStream(new FileInputStream("pessoa.ser"))) {
            Pessoa pessoaLida = (Pessoa) in.readObject();
            System.out.println("Objeto desserializado: " + pessoaLida);
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

📌 Explicação: Se um objeto da versão anterior (sem email) for desserializado, pode causar InvalidClassException, pois o serialVersionUID e a estrutura da classe mudaram.

3. Corrija o problema do exercício anterior implementando uma forma serializada compatível usando serialVersionUID.

import java.io.*;

class Pessoa implements Serializable {
    private static final long serialVersionUID = 1L;
    private String nome;
    private int idade;
    private transient String email; // Campo transient não será serializado

    public Pessoa(String nome, int idade, String email) {
        this.nome = nome;
        this.idade = idade;
        this.email = email;
    }

    @Override
    public String toString() {
        return "Pessoa{nome='" + nome + "', idade=" + idade + "', email='" + (email != null ? email : "N/A") + "'}";
    }
}

public class SerializacaoCorrigida {
    public static void main(String[] args) {
        // Desserializar objeto antigo sem email
        try (ObjectInputStream in = new ObjectInputStream(new FileInputStream("pessoa.ser"))) {
            Pessoa pessoaLida = (Pessoa) in.readObject();
            System.out.println("Objeto desserializado: " + pessoaLida);
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

📌 Explicação: O campo email foi marcado como transient, o que impede sua serialização e mantém a compatibilidade.

4. Demonstre como a serialização pode ser uma falha de segurança permitindo a modificação de um objeto privado.

import java.io.*;

class Usuario implements Serializable {
    private static final long serialVersionUID = 1L;
    private String nome;
    private String senha; // Senha não protegida!

    public Usuario(String nome, String senha) {
        this.nome = nome;
        this.senha = senha;
    }

    @Override
    public String toString() {
        return "Usuario{nome='" + nome + "', senha='" + senha + "'}";
    }
}

public class FalhaSeguranca {
    public static void main(String[] args) {
        Usuario usuario = new Usuario("admin", "1234");

        // Serializar usuário
        try (ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("usuario.ser"))) {
            out.writeObject(usuario);
        } catch (IOException e) {
            e.printStackTrace();
        }

        // Modificar o arquivo manualmente e desserializar (Simulando um ataque)
        try (ObjectInputStream in = new ObjectInputStream(new FileInputStream("usuario.ser"))) {
            Usuario usuarioHackeado = (Usuario) in.readObject();
            System.out.println("Usuário comprometido: " + usuarioHackeado);
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

📌 Explicação: A senha é armazenada em texto plano e pode ser extraída ou modificada por um invasor ao alterar o arquivo serializado.

5. Corrija o problema de segurança do exercício anterior tornando os campos sensíveis transient e implementando writeObject() e readObject().

import java.io.*;

class UsuarioSeguro implements Serializable {
    private static final long serialVersionUID = 1L;
    private String nome;
    private transient String senha; // Agora a senha não será serializada

    public UsuarioSeguro(String nome, String senha) {
        this.nome = nome;
        this.senha = senha;
    }

    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();
        out.writeObject(encrypt(senha)); // Salva senha criptografada
    }

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        in.defaultReadObject();
        senha = decrypt((String) in.readObject()); // Recupera senha descriptografada
    }

    private String encrypt(String senha) {
        return senha == null ? null : new StringBuilder(senha).reverse().toString(); // Simples inversão
    }

    private String decrypt(String senhaCriptografada) {
        return senhaCriptografada == null ? null : new StringBuilder(senhaCriptografada).reverse().toString();
    }

    @Override
    public String toString() {
        return "UsuarioSeguro{nome='" + nome + "', senha='" + senha + "'}";
    }
}

public class SegurancaCorrigida {
    public static void main(String[] args) {
        UsuarioSeguro usuario = new UsuarioSeguro("admin", "1234");

        // Serializar
        try (ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("usuarioSeguro.ser"))) {
            out.writeObject(usuario);
        } catch (IOException e) {
            e.printStackTrace();
        }

        // Desserializar
        try (ObjectInputStream in = new ObjectInputStream(new FileInputStream("usuarioSeguro.ser"))) {
            UsuarioSeguro usuarioLido = (UsuarioSeguro) in.readObject();
            System.out.println("Usuário seguro: " + usuarioLido);
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

📌 Explicação: O campo senha agora é transient, e os métodos writeObject() e readObject() aplicam uma criptografia simples.

5. Comparar serialização com outras abordagens

5.1 Persistência usando Serialização Java

import java.io.*;

// Classe serializável
class Pessoa implements Serializable {
    private static final long serialVersionUID = 1L;
    private String nome;
    private int idade;

    public Pessoa(String nome, int idade) {
        this.nome = nome;
        this.idade = idade;
    }

    @Override
    public String toString() {
        return "Pessoa{nome='" + nome + "', idade=" + idade + "}";
    }
}

public class SerializacaoJava {
    public static void main(String[] args) {
        Pessoa pessoa = new Pessoa("João", 30);

        // Serializar em arquivo
        try (ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("pessoa.ser"))) {
            out.writeObject(pessoa);
            System.out.println("Objeto serializado: " + pessoa);
        } catch (IOException e) {
            e.printStackTrace();
        }

        // Desserializar do arquivo
        try (ObjectInputStream in = new ObjectInputStream(new FileInputStream("pessoa.ser"))) {
            Pessoa pessoaLida = (Pessoa) in.readObject();
            System.out.println("Objeto desserializado: " + pessoaLida);
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

📌 Pontos positivos: Integrado ao Java, eficiente em binário.
📌 Pontos negativos: Problemas de compatibilidade ao mudar a classe, não legível para humanos.

5.2 Persistência usando JSON com Gson

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;

import java.io.*;

// Classe normal sem Serializable
class PessoaGson {
    private String nome;
    private int idade;

    public PessoaGson(String nome, int idade) {
        this.nome = nome;
        this.idade = idade;
    }

    @Override
    public String toString() {
        return "PessoaGson{nome='" + nome + "', idade=" + idade + "}";
    }
}

public class PersistenciaGson {
    public static void main(String[] args) {
        PessoaGson pessoa = new PessoaGson("João", 30);
        Gson gson = new GsonBuilder().setPrettyPrinting().create();

        // Serializar em JSON
        try (FileWriter writer = new FileWriter("pessoa.json")) {
            gson.toJson(pessoa, writer);
            System.out.println("Objeto serializado em JSON:\n" + gson.toJson(pessoa));
        } catch (IOException e) {
            e.printStackTrace();
        }

        // Desserializar do JSON
        try (Reader reader = new FileReader("pessoa.json")) {
            PessoaGson pessoaLida = gson.fromJson(reader, PessoaGson.class);
            System.out.println("Objeto desserializado: " + pessoaLida);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

📌 Pontos positivos: Legível, fácil de integrar com APIs e persistência de dados.
📌 Pontos negativos: JSON ocupa mais espaço e é um pouco mais lento que binário.

5.3 Persistência usando JSON com Jackson

import com.fasterxml.jackson.databind.ObjectMapper;
import java.io.*;

// Classe normal sem Serializable
class PessoaJackson {
    private String nome;
    private int idade;

    public PessoaJackson() {} // Jackson precisa de um construtor vazio

    public PessoaJackson(String nome, int idade) {
        this.nome = nome;
        this.idade = idade;
    }

    @Override
    public String toString() {
        return "PessoaJackson{nome='" + nome + "', idade=" + idade + "}";
    }
}

public class PersistenciaJackson {
    public static void main(String[] args) {
        PessoaJackson pessoa = new PessoaJackson("João", 30);
        ObjectMapper objectMapper = new ObjectMapper();

        // Serializar em JSON
        try {
            objectMapper.writeValue(new File("pessoa_jackson.json"), pessoa);
            System.out.println("Objeto serializado em JSON com Jackson");
        } catch (IOException e) {
            e.printStackTrace();
        }

        // Desserializar do JSON
        try {
            PessoaJackson pessoaLida = objectMapper.readValue(new File("pessoa_jackson.json"), PessoaJackson.class);
            System.out.println("Objeto desserializado: " + pessoaLida);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

📌 Pontos positivos: Alto desempenho, flexível, suporta diversas configurações.
📌 Pontos negativos: Requer bibliotecas externas, pode exigir configurações extras.

5.4 Comparação das abordagens

📌 Conclusão:

A serialização Java é eficiente, mas tem problemas de compatibilidade e não é legível.
O Gson é simples, fácil de usar e ideal para APIs.
O Jackson tem melhor desempenho e é mais configurável, sendo ótimo para grandes aplicações.

Item 86: Tenha cautela ao implementar a Serializable

Java Efetivo (livro) — Thu, 30 Jan 2025 17:03:22 +0000

1. Implementação Simples, Consequências Complexas

Basta adicionar implements Serializable para tornar uma classe serializável.
Serializar uma classe pode ter custos significativos a longo prazo.

2. Impacto na Evolução da Classe
Uma vez serializável, sua forma serializada se torna parte da API pública.
Alterações internas podem quebrar a compatibilidade com versões anteriores.
É possível manter compatibilidade manualmente (ObjectOutputStream.putFields e ObjectInputStream.readFields), mas é complexo.

3. Problemas com serialVersionUID

Cada classe serializável tem um identificador único (serialVersionUID).
Se não for especificado manualmente, o compilador o gera automaticamente.
Qualquer alteração na classe pode mudar esse ID, quebrando a compatibilidade e gerando InvalidClassException.

4. Riscos de Segurança

Serialização ignora construtores e pode burlar restrições da linguagem.
Objetos podem ser criados com valores inválidos ou permitir acesso não autorizado.
Dependência da desserialização padrão pode resultar em vulnerabilidades (ver Item 88).

5. Aumento na Complexidade de Testes

Classes serializáveis precisam ser testadas entre diferentes versões.
Quanto mais classes serializáveis, maior a matriz de testes necessária.
Formas serializadas mal planejadas dificultam a evolução do código.

6. Quando Serializar é Necessário
Essencial para frameworks que exigem serialização.
Útil em classes de valor (BigInteger, Instant) e coleções.
Classes que representam processos ativos (ThreadPool) geralmente não devem ser serializáveis

7. Serialização e Herança

Classes projetadas para herança geralmente não devem ser serializáveis.
Interfaces raramente devem estender Serializable, pois impõem um fardo extra a implementações futuras.
Exceções notáveis: Throwable (para propagação de exceções via RMI) e Component (para GUIs no Swing/AWT).

8. Problemas com Classes Internas

Classes internas não devem ser serializáveis devido a campos sintéticos não especificados.
Classes membros estáticas podem implementar Serializable.

9. Alternativas à Serialização

Usar o padrão proxy de serialização (Item 90) para maior controle.
Utilizar formatos como JSON ou XML para persistência e transmissão.

Capítulo 12: Serialização - Item 85: Prefira alternativas à serialização Java

Java Efetivo (livro) — Thu, 30 Jan 2025 16:36:47 +0000

A Serialização ainda é usada hoje, mas com muita cautela. Ela foi amplamente utilizada no passado para persistência de objetos e comunicação entre sistemas, mas devido a diversos problemas de segurança e eficiência, seu uso tem diminuído.

Atualmente, frameworks modernos e tecnologias como JSON, XML, Protobuf e Avro são preferidos para troca de dados, pois são mais seguros, interoperáveis e eficientes. No entanto, a serialização Java ainda pode ser encontrada em sistemas legados e em aplicações que precisam de compatibilidade com tecnologias antigas.

Se for realmente necessário usar serialização, recomenda-se adotar boas práticas de segurança, como filtragem de objetos e evitar desserialização de fontes não confiáveis.

Item 85: Prefira alternativas à serialização Java

O que é Serialização?

Processo de transformar um objeto em uma sequência de bytes para armazenamento ou transmissão.
Desserialização é o processo inverso, reconstruindo o objeto a partir dos bytes serializados.
Utiliza a interface Serializable no Java.

Problemas da Serialização Java

1. Superfície de Ataque Grande

O método readObject atua como um "construtor mágico", podendo instanciar objetos inesperados.
Qualquer classe que implemente Serializable pode ser um ponto de exploração.

2. Vulnerabilidades de Segurança

Possibilidade de execução remota de código (RCE) ao desserializar objetos de origem desconhecida.
Uso de gadgets (métodos chamados automaticamente durante a desserialização) para criar cadeias de ataque.

3. Bombas de Desserialização

Objetos que exigem grande poder computacional para serem desserializados.
Exemplo: HashSet profundamente aninhado.

Exemplo de bomba de desserialização:

import java.io.*;
import java.util.HashSet;

public class DeserializationBomb {
    public static void main(String[] args) throws Exception {
        HashSet<Object> root = new HashSet<>();
        HashSet<Object> s1 = root;
        HashSet<Object> s2;

        for (int i = 0; i < 100; i++) {
            s2 = new HashSet<>();
            s1.add(s2);
            s1 = s2;
        }

        try (ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("bomb.ser"))) {
            out.writeObject(root);
        }
    }
}

Alternativas à Serialização Java
JSON

Leve, legível e amplamente suportado. Exemplo com Gson:

import com.google.gson.Gson;

class Pessoa {
    String nome;
    int idade;
}

public class JsonExample {
    public static void main(String[] args) {
        Gson gson = new Gson();
        Pessoa pessoa = new Pessoa();
        pessoa.nome = "João";
        pessoa.idade = 30;

        String json = gson.toJson(pessoa);
        System.out.println(json);
    }
}

Protocol Buffers (Protobuf)

Binário e eficiente.
Necessita da definição de esquemas .proto.

Como Mitigar Riscos se a Serialização for Necessária

Evite Desserialização de Dados Não Confiáveis
Use Filtragem de Objetos (ObjectInputFilter desde Java 9)

ObjectInputFilter filter = info -> {
    if (info.serialClass() != null && info.serialClass().getName().equals("MinhaClasseSegura")) {
        return ObjectInputFilter.Status.ALLOWED;
    }
    return ObjectInputFilter.Status.REJECTED;
};

ObjectInputStream ois = new ObjectInputStream(new FileInputStream("objeto.ser"));
ois.setObjectInputFilter(filter);
Object obj = ois.readObject();

Utilize Lista Branca em vez de Lista Negra

Permita apenas classes explícitas na desserialização.

Conclusão

Evite ao máximo a Serialização Java em sistemas novos.
Prefira formatos mais seguros e eficientes como JSON, Protobuf e Jackson.
Se precisar desserializar objetos, use filtragem rigorosa para evitar ataques.

Exemplo do livro:

Resumo Bônus: Threads Virtuais

Java Efetivo (livro) — Thu, 16 Jan 2025 22:01:36 +0000

As threads virtuais são um recurso introduzido no Java 19 como parte do projeto Loom. Elas são leves e otimizadas, permitindo uma abordagem mais eficiente para programação concorrente.

1. O que são Threads Virtuais?

Threads implementadas inteiramente em software.
Criadas e gerenciadas pela JVM (Java Virtual Machine), não pelo sistema operacional.
Muito mais leves que threads do sistema operacional.

2. Características das Threads Virtuais

Leveza: Cada thread virtual ocupa muito menos memória que uma thread tradicional.
Altamente escaláveis: Permitem a execução de milhares (ou até milhões) de threads no mesmo processo.
Integração com o modelo de threads existente: São compatíveis com o java.lang.Thread.

3. Benefícios
Programação mais simples: Utilizam o modelo tradicional de threads, sem necessidade de complexidade adicional (como pools de threads).
Redução de bloqueios: Operações bloqueantes (como I/O) são tratadas de forma eficiente pela JVM.
Eficiência de recursos: Consomem menos memória e tempo de CPU comparadas às threads tradicionais.

4. Como criar Threads Virtuais?
Utiliza a classe Thread.ofVirtual(), disponível no Java 19+:

var thread = Thread.ofVirtual().start(() -> {
    System.out.println("Thread virtual em execução!");
});

Alternativamente, use um executor:

var executor = Executors.newVirtualThreadPerTaskExecutor();
executor.submit(() -> {
    System.out.println("Executando tarefa em thread virtual.");
});
executor.shutdown();

5. Diferenças entre Threads Virtuais e Tradicionais

6. Casos de Uso

Aplicações de servidor com muitos clientes simultâneos (alta concorrência).
Operações I/O intensivas (ex.: servidores HTTP).
Substituição de pools de threads tradicionais.

7. Considerações e Limitações

Estado experimental: Ainda não recomendado para produção (Java 19 e 20).
Compatibilidade: Algumas bibliotecas que usam operações bloqueantes podem não se beneficiar.
Diagnóstico: Ferramentas de monitoramento precisam suportar threads virtuais.

Item 84: Não dependa do agendador de threads

Java Efetivo (livro) — Thu, 16 Jan 2025 20:43:32 +0000

1. O papel do agendador de threads

Função: Determina quais threads executáveis devem rodar e por quanto tempo.
Variedade: Políticas variam entre sistemas operacionais.
Recomendação: Não dependa do comportamento do agendador para correção ou desempenho; isso compromete a portabilidade.

2. Estratégia para programas robustos
Manter threads executáveis equilibradas:

O número médio de threads executáveis deve ser próximo ao número de processadores disponíveis.
Evita sobrecarga no agendador e garante comportamento consistente.

Threads não executáveis:
O número total de threads pode ser maior, mas as threads em espera (não executáveis) não afetam a carga.

3. Técnicas para gerenciar threads
Evitar espera-ativa:

Threads não devem verificar constantemente o estado de um objeto compartilhado.
Isso aumenta o uso do processador e prejudica a eficiência.

Diminuir o número de threads executáveis:
Dimensionar corretamente pools de threads no Executor Framework.
Criar tarefas pequenas, mas não tão pequenas que a sobrecarga prejudique o desempenho.

4. Exemplo de má prática: espera-ativa

public class SlowCountDownLatch {
    private int count;

    public SlowCountDownLatch(int count) {
        this.count = count;
    }

    public void await() {
        while (count > 0) {
            // Espera-ativa: utiliza o processador desnecessariamente
        }
    }

    public void countDown() {
        if (count > 0) {
            count--;
        }
    }
}

Problema: Consome recursos excessivos, deixando o processador ocupado inutilmente.
Alternativa: Utilize CountDownLatch, que usa bloqueio eficiente.

5. Evitar o uso de Thread.yield
Não confiável:

Funciona de forma inconsistente em diferentes implementações da JVM.
Não resolve problemas de forma robusta ou portátil.

Exemplo incorreto:

while (!condition) {
    Thread.yield(); // Tentativa de "ceder" a CPU para outras threads
}

Solução: Reestruturar o código para reduzir threads executáveis.

6. Ajuste de prioridades de threads
Pouco portátil:

Prioridades de threads variam entre sistemas operacionais e JVMs. Uso recomendado:
Melhorar qualidade de serviço em aplicações funcionais. Evitar para corrigir problemas estruturais.

7. Conclusões

Não dependa do agendador para:
Correção do programa.
Otimização de desempenho.

Evite:

Uso de Thread.yield.
Ajustes excessivos de prioridade de threads.

Melhor abordagem:

Reestruturar aplicações para manter um número equilibrado de threads executáveis.

Exemplo do livro:

Exemplos de código para os sincronizadores

Java Efetivo (livro) — Thu, 09 Jan 2025 05:31:30 +0000

Aqui estão exemplos de código para os sincronizadores mencionados no item 80, com explicações de uso para facilitar o estudo:

1. CountDownLatch: Barreira de uso único para coordenação de threads
O CountDownLatch permite que uma ou mais threads aguardem até que um conjunto de operações realizadas por outras threads seja concluído.

import java.util.concurrent.CountDownLatch;

public class CountDownLatchExample {
    public static void main(String[] args) throws InterruptedException {
        int numberOfWorkers = 3;
        CountDownLatch latch = new CountDownLatch(numberOfWorkers);

        for (int i = 0; i < numberOfWorkers; i++) {
            new Thread(new Worker(latch, "Worker-" + i)).start();
        }

        System.out.println("Waiting for workers to finish...");
        latch.await(); // Aguarda todos os trabalhadores chamarem latch.countDown()
        System.out.println("All workers are done. Proceeding...");
    }

    static class Worker implements Runnable {
        private final CountDownLatch latch;
        private final String name;

        Worker(CountDownLatch latch, String name) {
            this.latch = latch;
            this.name = name;
        }

        @Override
        public void run() {
            System.out.println(name + " is working...");
            try {
                Thread.sleep((long) (Math.random() * 2000)); // Simula trabalho
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            System.out.println(name + " finished.");
            latch.countDown(); // Decrementa o contador
        }
    }
}

2. Semaphore: Controle de acesso a recursos compartilhados
O Semaphore gerencia um conjunto de permissões para controlar o acesso a recursos limitados.

import java.util.concurrent.Semaphore;

public class SemaphoreExample {
    public static void main(String[] args) {
        int permits = 2; // Número de permissões disponíveis
        Semaphore semaphore = new Semaphore(permits);

        for (int i = 1; i <= 5; i++) {
            new Thread(new Task(semaphore, "Task-" + i)).start();
        }
    }

    static class Task implements Runnable {
        private final Semaphore semaphore;
        private final String name;

        Task(Semaphore semaphore, String name) {
            this.semaphore = semaphore;
            this.name = name;
        }

        @Override
        public void run() {
            try {
                System.out.println(name + " is waiting for a permit...");
                semaphore.acquire(); // Adquire uma permissão
                System.out.println(name + " got a permit and is working...");
                Thread.sleep((long) (Math.random() * 2000)); // Simula trabalho
                System.out.println(name + " is releasing a permit.");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                semaphore.release(); // Libera a permissão
            }
        }
    }
}

3. CyclicBarrier: Sincronização em pontos de barreira reutilizáveis
O CyclicBarrier sincroniza várias threads em um ponto comum (barreira). Ele pode ser reutilizado após todas as threads atingirem o ponto de barreira.

import java.util.concurrent.CyclicBarrier;

public class CyclicBarrierExample {
    public static void main(String[] args) {
        int numberOfThreads = 3;
        CyclicBarrier barrier = new CyclicBarrier(numberOfThreads, () -> {
            System.out.println("All threads have reached the barrier. Proceeding...");
        });

        for (int i = 0; i < numberOfThreads; i++) {
            new Thread(new Task(barrier, "Thread-" + i)).start();
        }
    }

    static class Task implements Runnable {
        private final CyclicBarrier barrier;
        private final String name;

        Task(CyclicBarrier barrier, String name) {
            this.barrier = barrier;
            this.name = name;
        }

        @Override
        public void run() {
            try {
                System.out.println(name + " is performing some work...");
                Thread.sleep((long) (Math.random() * 2000)); // Simula trabalho
                System.out.println(name + " reached the barrier.");
                barrier.await(); // Aguarda todas as threads chegarem à barreira
                System.out.println(name + " passed the barrier.");
            } catch (Exception e) {
                Thread.currentThread().interrupt();
            }
        }
    }
}

4. Phaser: Sincronização avançada e dinâmica de threads
O Phaser é semelhante ao CyclicBarrier, mas suporta threads que entram e saem dinamicamente.

import java.util.concurrent.Phaser;

public class PhaserExample {
    public static void main(String[] args) {
        Phaser phaser = new Phaser(1); // Registra o "partida principal"

        for (int i = 0; i < 3; i++) {
            new Thread(new Task(phaser, "Task-" + i)).start();
        }

        // Avança para a próxima fase após garantir que todas as threads registradas concluíram
        System.out.println("Main thread waiting for phase 1 completion...");
        phaser.arriveAndAwaitAdvance();

        System.out.println("All tasks completed phase 1. Main thread moving to phase 2...");
        phaser.arriveAndDeregister(); // Desregistra a thread principal
    }

    static class Task implements Runnable {
        private final Phaser phaser;
        private final String name;

        Task(Phaser phaser, String name) {
            this.phaser = phaser;
            this.name = name;
            phaser.register(); // Registra a thread no Phaser
        }

        @Override
        public void run() {
            System.out.println(name + " is working on phase 1...");
            try {
                Thread.sleep((long) (Math.random() * 2000)); // Simula trabalho
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            System.out.println(name + " completed phase 1.");
            phaser.arriveAndAwaitAdvance(); // Indica chegada na fase atual e aguarda

            System.out.println(name + " is working on phase 2...");
            try {
                Thread.sleep((long) (Math.random() * 2000)); // Simula trabalho
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            System.out.println(name + " completed phase 2.");
            phaser.arriveAndDeregister(); // Indica chegada e desregistra
        }
    }
}

Esses exemplos ajudam a entender o funcionamento de cada sincronizador. Você pode experimentar ajustando os números de threads e tempos para observar os efeitos no comportamento de sincronização.