Mientras revisaba las formas de convertir arrays primitivos a Streams, encontré que char[]
no son soportados mientras que otros tipos de arrays primitivos son soportados. Alguna razón en particular para dejarlos fuera en el stream?
Por supuesto, la respuesta es "porque eso' es lo que decidieron los diseñadores'. No hay ninguna razón técnica por la que no pueda existir CharStream
.
Si quieres una justificación, normalmente tienes que acudir a la lista de correo de OpenJDK. La documentación del JDK's no tiene la costumbre de justificar por qué* algo es por lo que es.
Alguien preguntó
El uso de IntStream para representar char/byte stream es un poco inconveniente. ¿Deberíamos añadir 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 de JDK cada uno para estos formularios que no se usan casi nunca. Y si los añadimos, alguien podría exigiría short, float, o boolean.
Dicho de otro modo, si la gente insistiera en que tuviéramos todas las primitivas especializaciones, no tendríamos especializaciones primitivas. Lo cual sería peor que el status quo.
También dice lo mismo en otra parte
Si quieres tratar con ellos como chars, puedes bajarlos a
chars con bastante facilidad. No parece un caso de uso lo suficientemente importante como para tener todo un conjunto 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 en Google que utilicé fue
site:http://mail.openjdk.java.net/ charstream
Como dijo Eran, no es el único que falta.
Un BooleanStream
sería inútil, un ByteStream
(si existiera) puede ser manejado como un InputStream
o convertido a IntStream
(al igual que short
), y float
puede ser manejado como un DoubleStream
.
Como char
no es capaz de representar todos los caracteres de todas formas (ver linked), sería un bit de un flujo heredado. Aunque la mayoría de la gente no tiene que tratar con codepuntos de todos modos, por lo que puede parecer extraño. Me refiero a que usas String.charAt()
sin pensar "esto no'funciona realmente en todos los casos(.
Así que algunas cosas se dejaron fuera porque no se consideraron tan importantes. Como dice JB Nizet en la pregunta enlazada:
Los diseñadores eligieron explícitamente para evitar la explosión de clases y métodos limitando los flujos primitivos a 3 tipos, ya que los otros tipos (char, short, float) pueden ser representados por su equivalente más grande (int, double) sin ninguna penalización significativa en el rendimiento.
La razón por la que BooleanStream
sería inútil, es porque sólo tienes 2 valores y eso limita mucho las operaciones. No hay operaciones matemáticas que hacer y, de todas formas, ¿con qué frecuencia se trabaja con muchos valores booleanos?
No sólo las matrices char
no son compatibles.
Sólo hay 3 tipos de flujos primitivos: IntStream
, LongStream
y DoubleStream
.
Como resultado, Arrays
tiene métodos que convierten int[]
, long[]
y double[]
a 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.
"Car" es una parte dependiente de "Cuerda", que almacena valores UTF-16. Un símbolo de Unicode, un punto de código, es a veces un par de caracteres sustitutivos. Así que cualquier solución simple con caracteres sólo 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 code points, un "IntStream". Un flujo de caracteres no puede manejar directamente los pares sustitutos.
La otra razón más prosaica es que el modelo de "procesador" de la JVM usa un "punto" como el más pequeño "registro", manteniendo booleanos, bytes, shorts y también chars en un lugar de almacenamiento de tamaño tan grande. Para no inflar necesariamente las clases de Java, uno se abstuvo de todas las variantes de copia posibles.
En el futuro lejano uno podría esperar que los tipos primitivos permitidos funcionen como parámetros de tipo genérico, proporcionando una Lista<int>
. Entonces podríamos ver un Stream<char>
.
Por el momento es mejor evitar char
, y tal vez usar java.text.Normalizer
para una forma canónica única de puntos de código / cadenas de Unicode.