Ao percorrer as formas de conversão de matrizes primitivas em Streams, descobri que "car[]char[]
não são suportados enquanto outros tipos de matrizes primitivas são suportados. Alguma razão em particular para os deixar de fora no Stream?
Claro, a resposta é " porque isso'é o que os designers decidiram". Não há nenhuma razão técnica para que o CharStream
não pudesse existir.
Se quiser uma justificação, geralmente precisa de virar a lista de correio do OpenJDK. A documentação do JDK's não tem o hábito de justificar porquê* nada é a razão de ser.
Alguém perguntou
Utilizar o IntStream para representar o fluxo char/byte é um pouco inconveniente. Devemos acrescentar também CharStream e ByteStream?
A resposta de Brian Goetz (Java Language Architect) diz
resposta curta: não.
não vale mais 100K+ de pegada JDK para cada uma destas formas que são utilizados quase nunca. E se os acrescentássemos, alguém exigir curto prazo, flutuar, ou booleano.
dito de outra forma, se as pessoas insistissem que tínhamos todos os primitivos especializações, não teríamos especializações primitivas. Que seria pior do que o status quo.
Ele também diz o mesmo noutro lugar
Se quiser lidar com eles como chars, pode reduzi-los a chars com facilidade suficiente. Não parece ser um caso de uso suficientemente importante ter um conjunto ' não o seu conjunto de riachos. (O mesmo com Short, Byte, Float).
TL;DR: Não vale o custo de manutenção.
*No caso de você' estou curioso, a consulta do google que usei foi
site:http://mail.openjdk.java.net/ charstream
Como Eran disse, não é o único que falta...
Um BooleanStream
seria inútil, um byteStream
(se existisse) pode ser tratado como um InputStream
ou convertido para IntStream
(como pode ser curto
), e um float
pode ser tratado como um DoubleStream
.
Como "char" não é capaz de representar todos os caracteres de qualquer forma (ver link), seria um bit de um fluxo legado. Embora a maioria das pessoas não'não tem de lidar com codepoints de qualquer maneira, por isso pode parecer estranho. Quer dizer, utiliza-se String.charAt()
sem pensar " isto não't realmente funciona em todos os casos".
Assim, algumas coisas foram deixadas de fora por serem'não consideradas tão importantes. Como foi dito por JB Nizet na pergunta ligada:
Os designers optaram explicitamente por evitar a explosão das aulas e métodos, limitando as correntes primitivas a 3 tipos, uma vez que as outras os tipos (char, short, float) podem ser representados pelos seus maiores equivalente (int, duplo) sem qualquer penalização significativa de desempenho.
A razão pela qual o BooleanStream
seria inútil, é porque só se tem 2 valores e isso limita muito as operações. Não há's operações matemáticas para fazer, e com que frequência trabalha com muitos valores booleanos de qualquer maneira?
It's não são apenas char
arrays que não são suportados.
Existem apenas 3 tipos de correntes primitivas - IntStream
, LongStream
e DoubleStream
.
Como resultado, Arrays
tem métodos que convertem int[]
, long[]
e double[]
para as correntes primitivas correspondentes.
Não há métodos correspondentes para boolean[]
, byte[]
, short[]
, char[]
e float[]
, uma vez que estes tipos primitivos não têm correntes primitivas correspondentes.
O char
é uma parte dependente do String
- armazenamento de valores UTF-16. Um símbolo Unicode, um code point, é por vezes um par de caracteres de substituição. Assim, qualquer solução simples com caracteres apenas cobre parte do domínio Unicode.
Houve um tempo em que o char
tinha o seu próprio direito a ser um tipo público. Mas hoje em dia é melhor utilizar code points, um IntStream
. Um fluxo de "char" não podia lidar directamente com pares de substitutos.
A outra razão mais prosaica é que o modelo "processador" da JVM utiliza um int
como menor "registo", mantendo booleans, bytes, calções e também chars num local de armazenamento de tal tamanho. Para não inchar necessariamente as classes de java, abstém-se de todas as variantes de cópia possíveis.
No futuro longínquo pode-se esperar que os tipos primitivos possam funcionar como parâmetros genéricos de tipo, fornecendo uma Lista<int>
. Depois poderíamos ver um Stream<char>
.
De momento é melhor evitar char
, e talvez utilizar java.text.normalizer
para uma forma canónica única de pontos de código / strings Unicode.