En parcourant les moyens de convertir les tableaux primitifs en Streams, j'ai constaté que char[]
n'est pas supporté alors que les autres types de tableaux primitifs le sont. Y a-t-il une raison particulière de les laisser de côté dans le flux ?
Bien sûr, la réponse est "parce que c'est ce que les concepteurs ont décidé". Il n'y a aucune raison technique pour laquelle "CharStream" ne pourrait pas exister.
Si vous voulez une justification, vous devez généralement vous tourner vers la liste de diffusion OpenJDK. La documentation du JDK n'a pas l'habitude de justifier pourquoi* quoi que ce soit, c'est pour cela qu'elle existe.
Quelqu'un a demandé
Utiliser IntStream pour représenter le flux de caractères/octets est un peu peu pratique. Devrions-nous ajouter CharStream et ByteStream également ?
La réponse de Brian Goetz (Java Language Architect) dit
Réponse brève : non.
Il ne vaut pas la peine d'ajouter 100K+ d'empreinte JDK pour chacun de ces formulaires qui ne sont presque jamais utilisés. Et si nous les ajoutions, quelqu'un demande courte, flottante ou booléenne.
Autrement dit, si les gens insistaient pour que nous ayons tous les primitifs , nous n'aurions pas de spécialisations primitives. Ce qui serait pire que le statu quo.
Il dit aussi la même chose ailleurs
Si vous voulez les traiter comme des chars, vous pouvez les rétrograder à de manière assez simple. Ne semble pas être un cas d'utilisation assez important d'avoir un tout autre ensemble de cours d'eau. (Pareil pour Short, Byte, Flotter).
TL;DR : ne vaut pas le coût de l'entretien.
*Au cas où vous seriez curieux, la requête google que j'ai utilisée était
site:http://mail.openjdk.java.net/ charstream
Comme l'a dit Eran, ce n'est pas le seul qui manque.
Un "BooleanStream" serait inutile, un "ByteStream" (s'il existait) peut être traité comme un "InputStream" ou converti en "IntStream" (comme peut l'être un "Short"), et un "Float" peut être traité comme un "DoubleStream".
Comme le "char" n'est pas capable de représenter tous les caractères de toute façon (voir lien), il serait un bit d'un flux existant. Bien que la plupart des gens n'aient pas à gérer de points de code de toute façon, cela peut sembler étrange. Je veux dire que vous utilisez String.charAt()
sans penser "cela ne fonctionne pas vraiment dans tous les cas".
Certaines choses ont donc été omises parce qu'elles n'étaient pas jugées si importantes. Comme l'a dit JB Nizet dans la question liée :
, les concepteurs ont explicitement choisi d'éviter l'explosion des classes et en limitant les flux primitifs à 3 types, puisque les autres les types (char, short, float) peuvent être représentés par leur équivalent (int, double) sans aucune pénalité de performance significative.
La raison pour laquelle BooleanStream
serait inutile, est que vous n'avez que 2 valeurs et que cela limite beaucoup les opérations. Il n'y a pas d'opérations mathématiques à faire, et combien de fois travaillez-vous avec beaucoup de valeurs booléennes de toute façon ?
Il n'y a pas que les tableaux de "char" qui ne sont pas pris en charge.
Il n'y a que 3 types de flux primitifs - "IntStream", "LongStream" et "DoubleStream".
En conséquence, Arrays
a des méthodes qui convertissent int[]
, long[]
et double[]
en flux primitifs correspondants.
Il n'y a pas de méthodes correspondantes pour boolean[]
, byte[]
, short[]
, char[]
et float[]
, puisque ces types primitifs n'ont pas de flux primitifs correspondants.
Char est une partie dépendante de String, qui stocke les valeurs UTF-16. Un symbole Unicode, un point de code, est parfois une paire de caractères de substitution. Ainsi, toute solution simple avec des caractères ne couvre qu'une partie du domaine Unicode.
Il fut un temps où les "chars" avaient leur propre droit d'être un type public. Mais aujourd'hui, il est préférable d'utiliser des points de code, un IntStream
. Un flux de char ne pourrait pas gérer directement les paires de substituts.
L'autre raison plus prosaïque est que le modèle de "processeur" de la JVM utilise un "Int" comme plus petit "registre", gardant les booléens, les octets, les courts et aussi les caractères dans un emplacement de stockage de la taille d'un Int. Pour ne pas nécessairement gonfler les classes java, on s'est abstenu de toutes les variantes de copie possibles.
Dans le futur lointain, on pourrait s'attendre à ce que les types primitifs soient autorisés à fonctionner comme des paramètres de type génériques, fournissant une "liste" (ListStream<char>
.
Pour le moment, il vaut mieux éviter char
, et peut-être utiliser java.text.Normalizer
pour une forme canonique unique de points de code / chaînes Unicode.