Me parece que la diferenciación de Java de char y codepoint es extraña y está fuera de lugar.

Por ejemplo, una cadena es una matriz de caracteres o "letras que aparecen en un alfabeto"; en contraste con el punto de código que PUEDE ser una sola letra o posiblemente un par compuesto o sustituto. Sin embargo, Java define un carácter de una cadena como unchar que no puede ser compuesto o contener un sustituto del punto de código y comoint (esto esta bien).

Pero entonceslength() parece devolver el número de puntos de código mientrascodePointCount() también devuelve el número de puntos de código, pero en su lugar combina caracteres compuestos ... ¿lo que termina siendo realmente el recuento real de puntos de código?

Se siente como sicharAt() debería devolver unString para que traigan compuestos y sustitutos y el resultado delength() debería intercambiar concodePointCount().

La implementación original se siente un poco al revés. ¿Hay alguna razón para la forma en que está diseñada?

Actualizar:codePointAt(), codePointBefore()

También vale la pena señalar quecodePointAt() ycodePointBefore() acepta un índice como parámetro, sin embargo, el índice actúa sobre caracteres y tiene un rango de0 alength() - 1 y por lo tanto no se basa en el número de puntos de código en la cadena, como se podría suponer.

Actualizar:equalsIgnoreCase()

String.equalsIgnoreCase () usa el términonormalization para describir lo que hace antes de comparar cadenas. Este es un nombre inapropiado ya que la normalización en el contexto de una cadena Unicode puede significar algo completamente diferente. Lo que quieren decir es que usan plegado de cajas.