Problema al analizar el escape de Unicode en un literal de Java 6 String ...?

Question

¿Por qué compilar esto en Java 6 (Sun 1.6.0_16):

System.out.println("\u000B"); 

... pero no esto:

System.out.println("\u000A"); 

En este programa:

public class Test { 
    public static void main(String argv[]) { 
    System.out.println("\u000A"); 
    } 
} 

consigo a

Test.java:3: unclosed string literal 
System.out.println("\u000A"); 

¿Que está pasando aqui?

Answer 1

El problema es que el reemplazo Unicode se realiza muy temprano en la compilación. Los escapes Unicode no son solo válidos en cadenas y literales de caracteres (como otras secuencias de escape como \t) - son válidos en cualquier parte en el código. Se describen en un área diferente de la especificación: section 3.3 en lugar de section 3.10.6; solo el último es acerca de caracteres y cadena literal secuencias de escape.

Básicamente, la sección 3 de la especificación de lectura para más detalles sobre la estructura léxica :)

lo que el código se realidad equivalente a:

public class Test { 
    public static void main(String argv[]) { 
    System.out.println(" 
"); 
    } 
} 

... que claramente no es válida código. Para retorno de carro y avance de línea, básicamente es mejor utilizar las secuencias de escape "\ r" y "\ n".

Personalmente ver esta manipulación de Unicode escapar como un defecto en Java, pero no hay mucho que podamos hacer al respecto ahora :(

Answer 2

escapa Unicode se expanden antes del análisis léxico. El hecho de que el escape Unicode aparece dentro de una cadena literal es irrelevante. Ver JLS 3.2.

• Resource

Answer 3

es porque \ u000a = \ n y el compilador procesa el origen de Java para convertirlo en tokens, por lo que no puede usar ese carácter Unicode en su código. Lo mismo para \ u000d = \ r

Answer 4

Si no me equivoco, para evitar la prepocessing que podríamos solucionar cambiando la línea en:

System.out.println((char)10); 

La limitación es que por ser un CHAR, que es la extensión será de 0 a 255.