Mientras revisaba las formas de convertir matrices primitivas en Streams, descubrí que char[] no son compatibles, mientras que otros tipos de matrices primitivas sí lo son. ¿Alguna razón en particular para dejarlos fuera de la corriente?
No son solo las char de caracteres las que no son compatibles.
Solo hay 3 tipos de flujos primitivos: IntStream , LongStream y DoubleStream .
Como resultado, Arrays tiene métodos que convierten int[] , long[] y double[] en los flujos primitivos correspondientes.
No hay métodos correspondientes para boolean[] , byte[] , short[] , char[] y float[] , ya que estos tipos primitivos no tienen flujos primitivos correspondientes.
Como dijo Eran, no es el único que falta.
Un BooleanStream sería inútil, un ByteStream (si existiera) puede manejarse como InputStream o convertirse en IntStream (al igual que short ), y float puede manejarse como DoubleStream .
Como char no puede representar todos los caracteres de todos modos (ver enlace), sería una transmisión heredada. Aunque la mayoría de las personas no tienen que lidiar con puntos de código de todos modos, puede parecer extraño. Quiero decir que usas String.charAt() sin pensar "esto no funciona en todos los casos".
Así que algunas cosas quedaron fuera porque no se consideraron tan importantes. Como dijo JB Nizet en la pregunta vinculada :
Los diseñadores eligieron explícitamente evitar la explosión de clases y métodos al limitar los flujos primitivos a 3 tipos, ya que los otros tipos (char, short, float) pueden representarse por su equivalente más grande (int, double) sin ninguna penalización de rendimiento significativa.
La razón por la que BooleanStream sería inútil es porque solo tiene 2 valores y eso limita mucho las operaciones. No hay operaciones matemáticas que hacer, y ¿con qué frecuencia trabaja con muchos valores booleanos de todos modos?
Como se puede ver en los comentarios, no se necesita un BooleanStream . Si lo fuera, habría muchos casos de uso reales en lugar de situaciones teóricas, un caso de uso que se remonta a Java 1.4 y una comparación falaz con el ciclo while .
Por supuesto, la respuesta es " porque eso es lo que decidieron los diseñadores ". No hay ninguna razón técnica por la que CharStream no pueda existir.
Si desea una justificación, generalmente debe activar la lista de correo de OpenJDK *. La documentación de JDK no suele justificar por qué algo es por qué es.
alguien preguntó
Usar IntStream para representar el flujo de caracteres/bytes es un poco inconveniente. ¿Deberíamos agregar CharStream y ByteStream también?
La respuesta de Brian Goetz (Java Language Architect) dice
Respuesta corta: no.
No vale la pena otros 100K+ de huella JDK cada uno para estos formularios que casi nunca se usan. Y si los agregamos, alguien exigirá short, float o boolean.
Dicho de otra manera, si la gente insistiera en que tuviéramos todas las especializaciones primitivas, no tendríamos especializaciones primitivas. Lo que sería peor que el statu quo.
También dice lo mismo en otros lugares.
Si desea tratar con ellos como caracteres, puede reducirlos a caracteres con bastante facilidad. No parece un caso de uso lo suficientemente importante como para tener otro conjunto completo de flujos. (Lo mismo con Short, Byte, Float).
TL; DR: No vale la pena el costo de mantenimiento.
*En caso de que tengas curiosidad, la consulta de Google que utilicé fue
site:http://mail.openjdk.java.net/ charstreamchar es una parte dependiente de String : almacena valores UTF-16. Un símbolo Unicode, un punto de código , a veces es un par de caracteres sustitutos. Entonces, cualquier solución simple con caracteres solo cubre parte del dominio Unicode.
Hubo un tiempo en que char tenía su propio derecho a ser un tipo público. Pero hoy en día es mejor usar puntos de código , un IntStream . Una secuencia de char no podía manejar directamente los pares sustitutos.
La otra razón más prosaica es que el modelo de "procesador" de JVM usa un int como "registro" más pequeño, manteniendo booleanos, bytes, cortos y también caracteres en una ubicación de almacenamiento de tamaño int. Para no inflar necesariamente las clases de Java, uno se abstuvo de todas las posibles variantes de copia.
En un futuro lejano , se podría esperar que los tipos primitivos funcionaran como parámetros de tipo genérico, proporcionando un List<int> . Entonces podríamos ver un Stream<char> .
Por el momento, mejor evite char , y tal vez use java.text.Normalizer para una forma canónica única de puntos de código/cadenas Unicode.