Por que String.chars () é um fluxo de entradas no Java 8?

No Java 8, existe um novo método String.chars()que retorna um fluxo de ints ( IntStream) que representa os códigos de caracteres. Eu acho que muitas pessoas esperariam um fluxo de chars aqui. Qual foi a motivação para projetar a API dessa maneira?

Como outros já mencionaram, a decisão de design por trás disso foi impedir a explosão de métodos e classes.

Ainda assim, pessoalmente, acho que foi uma péssima decisão, e deveria, dado que eles não querem tomar CharStream, o que é razoável, métodos diferentes em vez de chars(), eu pensaria em:

• Stream<Character> chars(), que fornece um fluxo de caracteres de caixas, que terão alguma penalidade no desempenho de luz.
• IntStream unboxedChars(), que seria usado para o código de desempenho.

No entanto , em vez de focar no motivo de isso ser feito atualmente, acho que essa resposta deve se concentrar em mostrar uma maneira de fazer isso com a API que obtivemos com o Java 8.

No Java 7, eu teria feito assim:

for (int i = 0; i < hello.length(); i++) {
    System.out.println(hello.charAt(i));
}

E acho que um método razoável para fazer isso no Java 8 é o seguinte:

hello.chars()
        .mapToObj(i -> (char)i)
        .forEach(System.out::println);

Aqui eu obtenho um IntStreame mapeio-o para um objeto via lambda i -> (char)i, isso o colocará automaticamente em um Stream<Character>, e então podemos fazer o que queremos, e ainda usar as referências de método como um plus.

Esteja ciente de que você deve fazer mapToObj, se você esquecer e usar map, nada reclamará, mas você ainda terá um IntStreame poderá ficar se perguntando por que ele imprime os valores inteiros em vez das cadeias que representam os caracteres.

Outras alternativas feias para Java 8:

Ao permanecer em um IntStreame desejando imprimi-los, você não poderá mais usar referências de métodos para imprimir:

hello.chars()
        .forEach(i -> System.out.println((char)i));

Além disso, o uso de referências de métodos ao seu próprio método não funciona mais! Considere o seguinte:

private void print(char c) {
    System.out.println(c);
}

e depois

hello.chars()
        .forEach(this::print);

Isso gerará um erro de compilação, pois possivelmente há uma conversão com perdas.

Conclusão:

A API foi projetada dessa maneira, por não querer adicionar CharStream, eu pessoalmente acho que o método deve retornar a Stream<Character>, e a solução atualmente é usar mapToObj(i -> (char)i)uma IntStreampara poder trabalhar corretamente com eles.

A resposta do skiwi já cobriu muitos dos principais pontos. Vou preencher um pouco mais de fundo.

O design de qualquer API é uma série de compensações. Em Java, uma das questões difíceis é lidar com decisões de design que foram tomadas há muito tempo.

As primitivas estão em Java desde a 1.0. Eles tornam o Java uma linguagem orientada a objetos "impura", uma vez que as primitivas não são objetos. A adição de primitivos foi, acredito, uma decisão pragmática para melhorar o desempenho à custa da pureza orientada a objetos.

Essa é uma troca que ainda estamos vivendo hoje, quase 20 anos depois. O recurso de caixa automática adicionado no Java 5 eliminou principalmente a necessidade de desorganizar o código-fonte com chamadas de métodos de boxe e unboxing, mas a sobrecarga ainda está lá. Em muitos casos, isso não é perceptível. No entanto, se você realizasse boxe ou unboxing dentro de um loop interno, veria que isso pode impor uma sobrecarga significativa na CPU e na coleta de lixo.

Ao projetar a API do Streams, ficou claro que precisávamos oferecer suporte a primitivos. A sobrecarga de boxe / unboxing mataria qualquer benefício de desempenho do paralelismo. No entanto, não queríamos oferecer suporte a todas as primitivas, pois isso acrescentaria uma enorme quantidade de confusão à API. (Você realmente pode ver o uso de um ShortStream?) "Todos" ou "nenhum" são lugares confortáveis ​​para um design, mas nenhum deles era aceitável. Então tivemos que encontrar um valor razoável de "alguns". Nós acabamos com especializações primitivos para int, long, e double. (Pessoalmente eu teria deixado de foraint mas sou apenas eu.)

Por CharSequence.chars()considerarmos o retorno Stream<Character>(um protótipo inicial pode ter implementado isso), mas foi rejeitado por causa da sobrecarga do boxe. Considerando que uma String tem charvalores como primitivos, parece um erro impor boxe incondicionalmente quando o chamador provavelmente apenas processa um pouco o valor e o desmarca de volta em uma string.

Também consideramos uma CharStreamespecialização primitiva, mas seu uso pareceria bastante restrito em comparação com a quantidade de volume que acrescentaria à API. Não parecia valer a pena adicioná-lo.

A penalidade que isso impõe aos chamadores é que eles precisam saber que os valores IntStreamcontidos charsão representados como intse que a transmissão deve ser feita no local apropriado. Isso é duplamente confuso, pois há chamadas de API sobrecarregadas como PrintStream.print(char)e PrintStream.print(int)que diferem acentuadamente em seu comportamento. Um ponto adicional de confusão possivelmente surge porque a codePoints()chamada também retorna um, IntStreammas os valores que ela contém são bem diferentes.

Portanto, isso se resume a escolher pragmaticamente entre várias alternativas:

1. Não poderíamos fornecer especializações primitivas, resultando em uma API simples, elegante e consistente, mas que impõe um alto desempenho e sobrecarga de GC;

2. poderíamos fornecer um conjunto completo de especializações primitivas, com o custo de sobrecarregar a API e impor uma carga de manutenção aos desenvolvedores do JDK; ou

3. poderíamos fornecer um subconjunto de especializações primitivas, fornecendo uma API de tamanho médio e alto desempenho que impõe uma carga relativamente pequena aos chamadores em uma variedade bastante estreita de casos de uso (processamento de caracteres).

Nós escolhemos o último.