10

I was playing around with Java Unicode Escapes and accidentally found the following interesting oddities. Here is the code that I wrote:

static void main(String... args) {
        /*
         * \u0027 - single quote
         */
        char e = \u0027\n\u0027;
        char f = '\'';

        System.out.println(e == f);
        
        //output: true
}

Looking at the compiled code, the Java compiler translated them into the same character literal.

char e = '\'';
char f = '\'';

By what conversion rules e has become a ' instead of a linefeed \n?

BTW I am using Oracle JDK 19 on Windows 11.

EDIT: It seems like the issue is related to Java compilers failing to work according to the Java Language Specification.

EDIT: It seems like the issue happens when Oracle JDK 19 runs in JLS 18 mode. (I am not sure how to say this properly)

Holger
  • 285,553
  • 42
  • 434
  • 765
Microtribute
  • 962
  • 10
  • 24
  • 3
    [Cannot reproduce](https://ideone.com/TDsWec) – Andy Turner Nov 08 '22 at 15:35
  • Can reproduce with VSC. But not with `java.exe` (18). But looking at the decompiled bytecode in recaf (CFR) shows a comparison between `10` and `39` https://i.imgur.com/gf2OLMU.png Here is `javap -v`: https://i.imgur.com/dBjxGAu.png – Zabuzard Nov 08 '22 at 15:37
  • @AndyTurner I used Oracle JDK 19 on Windows 11. – Microtribute Nov 08 '22 at 15:38
  • The compiler that VSC used for me made it true. The actual `javac.exe` (18) makes it false for me. – Zabuzard Nov 08 '22 at 15:41
  • @Zabuzard Possibly related to a bug of JDK 19... the result you had is exactly what I would have expected. – Microtribute Nov 08 '22 at 15:42
  • Can you specify exactly what version of the JDK are you using? If it's a bug in the JDK (and it looks like the only thing it could be) you need to provide the vendor (IBM, OpenJDK...) and the exact version number (like 19.0.1) – Deltharis Nov 08 '22 at 15:49
  • 1
    Could verify behaviour with OpenJDK 1.8.0_322 – Gyro Gearless Nov 08 '22 at 15:54
  • 4
    I can reproduce this in Eclipse with sapjvm8. Looking at the bytecode it produces `bipush 39` twice. It happens for any backslash character as well, not just `\n`. – TiiJ7 Nov 08 '22 at 15:55
  • Can't reproduce with intellij on opnjdk 11.0.12 nor 19.0.1. Windows 10. – Deltharis Nov 08 '22 at 15:57
  • 1
    @TiiJ7 Yeah I used Eclipse, even if I set the JRE environment to JDK 19, Eclipse seems to choose JRE 18 shipped out of the box regardless. When I compile the code with Oracle JDK 19, the issue does not happen. https://imgur.com/a/63mMoYi – Microtribute Nov 08 '22 at 16:03
  • 1
    @TiiJ7 Eclipse uses the binaries included in the Oracle JDK 19, however, it runs in Java v18 mode. (Eclipse does not support Java 19 yet). I think that's when the issue occurs. – Microtribute Nov 08 '22 at 16:26
  • Not quite sure how you managed to compile that... – g00se Nov 08 '22 at 17:58
  • 3
    Eclipse has it’s own compiler, so this is a bug specific to this compiler. – Holger Nov 22 '22 at 13:27
  • 1
    I know I'm late, but I can confirm that the Eclipse compiler ECJ produces this behaviour in all versions between 3.19.0 (earlier ones I didn't bother testing as they didn't immediately work in my Gradle script) and 3.32.0. That seems to be independent from which JDK its running on (as I expected): On 11, 17 and 19 it produces the same incorrect output. – Joachim Sauer Mar 07 '23 at 10:24
  • I've filed [this bug](https://github.com/eclipse-jdt/eclipse.jdt.core/issues/827). I suspect the bug is fairly easy to fix once pinpointed and not very important in the grand scheme of things. But still somewhat fascinating for me. – Joachim Sauer Mar 13 '23 at 11:46
  • AFAIK, a primitive data type `char` represents a single character (merely the first `\u0027`)? – JosefZ Apr 07 '23 at 15:01

0 Answers0