Como posso copiar coleções com segurança?

No passado, eu disse para copiar com segurança uma coleção, algo como:

public static void doThing(List<String> strs) {
    List<String> newStrs = new ArrayList<>(strs);

ou

public static void doThing(NavigableSet<String> strs) {
    NavigableSet<String> newStrs = new TreeSet<>(strs);

Mas esses construtores de "cópia", métodos e fluxos de criação estática semelhantes, são realmente seguros e onde as regras são especificadas? Por segurança, quero dizer, são as garantias básicas de integridade semântica oferecidas pela linguagem Java e coleções impostas a um chamador mal-intencionado, assumindo o backup de um razoável SecurityManagere que não há falhas.

Estou feliz com o lançamento método ConcurrentModificationException, NullPointerException, IllegalArgumentException, ClassCastException, etc., ou talvez mesmo pendurado.

Eu escolhi Stringcomo exemplo de um argumento de tipo imutável. Para esta pergunta, não estou interessado em cópias profundas para coleções de tipos mutáveis ​​que têm suas próprias dicas.

(Para ser claro, observei o código-fonte do OpenJDK e tenho algum tipo de resposta para ArrayListe TreeSet.)

Não há proteção real contra códigos maliciosos intencionalmente executados na mesma JVM em APIs comuns, como a API Collection.

Como pode ser facilmente demonstrado:

public static void main(String[] args) throws InterruptedException {
    Object[] array = { "foo", "bar", "baz", "and", "another", "string" };
    array[array.length - 1] = new Object() {
        @Override
        public String toString() {
            Collections.shuffle(Arrays.asList(array));
            return "string";
        }
    };
    doThing(new ArrayList<String>() {
        @Override public Object[] toArray() {
            return array;
        }
    });
}

public static void doThing(List<String> strs) {
    List<String> newStrs = new ArrayList<>(strs);

    System.out.println("made a safe copy " + newStrs);
    for(int i = 0; i < 10; i++) {
        System.out.println(newStrs);
    }
}

made a safe copy [foo, bar, baz, and, another, string]
[bar, and, string, string, another, foo]
[and, baz, bar, string, string, string]
[another, baz, and, foo, bar, string]
[another, bar, and, foo, string, and]
[another, baz, string, another, and, foo]
[string, and, another, foo, string, foo]
[baz, string, foo, and, baz, string]
[bar, another, string, and, another, baz]
[bar, string, foo, string, baz, and]
[bar, string, bar, another, and, foo]

Como você pode ver, esperar que um List<String>não garanta uma lista de Stringinstâncias. Devido à eliminação de tipos e tipos brutos, não há nem mesmo uma correção possível no lado da implementação da lista.

A outra coisa pela qual você pode culpar ArrayListo construtor é a confiança na toArrayimplementação da coleção recebida . TreeMapnão é afetado da mesma maneira, mas apenas porque não há ganho de desempenho ao passar a matriz, como na construção de um ArrayList. Nenhuma classe garante uma proteção no construtor.

Normalmente, não faz sentido tentar escrever código assumindo intencionalmente código malicioso em cada esquina. Há muito o que fazer, para proteger contra tudo. Essa proteção é útil apenas para códigos que realmente encapsulam uma ação que pode dar a um chamador mal-intencionado acesso a algo que já não podia acessar sem esse código.

Se você precisar de segurança para um código específico, use

public static void doThing(List<String> strs) {
    String[] content = strs.toArray(new String[0]);
    List<String> newStrs = new ArrayList<>(Arrays.asList(content));

    System.out.println("made a safe copy " + newStrs);
    for(int i = 0; i < 10; i++) {
        System.out.println(newStrs);
    }
}

Então, você pode ter certeza de que newStrscontém apenas cadeias e não pode ser modificado por outro código após sua construção.

Ou use List<String> newStrs = List.of(strs.toArray(new String[0]));com o Java 9 ou mais recente
Observe que o Java 10 List.copyOf(strs)faz o mesmo, mas sua documentação não afirma que é garantido que não confie no toArraymétodo da coleção recebida . Assim List.of(…), chamar , que definitivamente fará uma cópia caso retorne uma lista baseada em array, é mais seguro.

Como nenhum chamador pode alterar a maneira, as matrizes funcionam, despejar a coleção recebida em uma matriz e, em seguida, preencher a nova coleção, sempre tornará a cópia segura. Como a coleção pode conter uma referência à matriz retornada, como demonstrado acima, ela pode alterá-la durante a fase de cópia, mas não pode afetar a cópia na coleção.

Portanto, qualquer verificação de consistência deve ser feita após o elemento específico ter sido recuperado da matriz ou da coleção resultante como um todo.

Eu preferiria deixar essas informações em comentário, mas não tenho reputação suficiente, desculpe :) Vou tentar explicá-las o mais detalhadamente possível.

Em vez de algo como o constmodificador usado em C ++ para marcar funções-membro que não deveriam modificar o conteúdo do objeto, originalmente em Java era usado o conceito de "imutabilidade". O encapsulamento (ou OCP, Princípio Aberto-Fechado) deveria proteger contra quaisquer mutações inesperadas (mudanças) de um objeto. É claro que a API de reflexão anda por aí; o acesso direto à memória faz o mesmo; isso é mais sobre fotografar a própria perna :)

java.util.Collectionem si é uma interface mutável: possui um addmétodo que deve modificar a coleção. É claro que o programador pode agrupar a coleção em algo que será lançado ... e todas as exceções de tempo de execução acontecerão porque outro programador não conseguiu ler o javadoc, o que claramente diz que a coleção é imutável.

Decidi usar java.util.Iterabletype para expor coleção imutável em minhas interfaces. Semanticamente Iterable, não possui tal característica de coleção como "mutabilidade". Ainda (provavelmente) você poderá modificar coleções subjacentes por meio de fluxos.

JIC, para expor mapas de maneira imutável java.util.Function<K,V>pode ser usado (o getmétodo do mapa se encaixa nessa definição)