java - reales - libro de android studio en español pdf
¿Por qué / R se comporta de manera diferente en expresiones regulares entre Java 8 y Java 9? (2)
El siguiente código se compila en Java 8 y 9, pero se comporta de manera diferente.
class Simple {
static String sample = "/nEn un lugar/r/nde la Mancha/nde cuyo nombre/r/nno quiero acordarme";
public static void main(String args[]){
String[] chunks = sample.split("//R//R");
for (String chunk: chunks) {
System.out.println("Chunk : "+chunk);
}
}
}
Cuando lo ejecuto con Java 8, devuelve:
Chunk :
En un lugar
de la Mancha
de cuyo nombre
no quiero acordarme
Pero cuando lo ejecuto con Java 9, el resultado es diferente:
Chunk :
En un lugar
Chunk : de la Mancha
de cuyo nombre
Chunk : no quiero acordarme
¿Por qué?
Era un error en Java 8 y se solucionó: JDK-8176029: "Linebreak matcher no es equivalente al patrón como se indica en javadoc" .
Ver también: Java-8 regex negativo lookbehind con `/ R`
La
documentación de Java
no cumple con el estándar Unicode.
El Javadoc confunde lo que se supone que
/R
debe coincidir.
Se lee:
/RCualquier secuencia de salto de línea Unicode, es equivalente a/u000D/u000A|[/u000A/u000B/u000C/u000D/u0085/u2028/u2029]
Esa documentación de Java tiene errores. En su sección sobre Saltos de línea R1.6, la Norma técnica Unicode # 18 sobre expresiones regulares establece claramente:
Se recomienda encarecidamente que haya un metacarácter de expresión regular, como "/ R", para hacer coincidir todos los caracteres y secuencias de final de línea enumerados anteriormente (por ejemplo, en el n. ° 1). Esto correspondería a algo equivalente a la siguiente expresión. Esa expresión es un poco complicada por la necesidad de evitar el respaldo.
(?:/u{D A}|(?!/u{D A})[/u{A}-/u{D}/u{85}/u{2028}/u{2029}]
En otras palabras, solo puede coincidir con una secuencia de dos puntos de código CR + LF (retorno de carro + salto de línea)
o, de lo contrario,
un único punto de código de ese conjunto siempre que no sea solo un retorno de carro seguido de un salto de línea .
Eso es porque no está
permitido realizar copias de seguridad
.
CRLF debe ser atómico para que
/R
funcione correctamente.
Por lo tanto, Java 9 ya no se ajusta a lo que R1.6 recomienda encarecidamente. Además, ahora está haciendo algo que se suponía que NO debía hacer, y no hizo, en Java 8.
Parece que es hora de que le vuelva a gritar a Sherman (léase: Xueming Shen). He trabajado con él antes en estos asuntos esenciales de conformidad formal.