Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raw String Literals Removed From Java 12 as Feature Set Frozen

infoq.com

Post reply on HN
Print view View original

1–10 of 60 posts

Re: Raw String Literals Removed From Java 12 as Feature Set Frozen

#2

Post by mabbo »

JEP325 seems like a nice little improvement. Just a linguistic trick but still lovely.

   int numLetters = switch (day) {
       case MONDAY, FRIDAY, SUNDAY -> 6;
       case TUESDAY                -> 7;
       case THURSDAY, SATURDAY     -> 8;
       case WEDNESDAY              -> 9;
   };
Switches can return values, and can have multiple cases on the same line.

I'm sure in 2 years when my organization gets around to switching to Java 12, I'll enjoy using it.

Re: Raw String Literals Removed From Java 12 as Feature Set Frozen

#4

Post by helfire »

mabbo wrote: post #2

JEP325 seems like a nice little improvement. Just a linguistic trick but still lovely. int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; }; Switches can return values, and can have multiple cases on the same line. I'm sure in 2 years when my organization gets around to switching to Java 12, I'll enjoy using it.

Java 12 is not a long term support release and will only be supported until September 2019 (so don't switch to it in 2 years :).

Interesting to see the faster pace releases to get feedback on features, but many major libraries are just getting Java 11 support.

Re: Raw String Literals Removed From Java 12 as Feature Set Frozen

#5

Post by moefh »

Java Unicode escapes are kind of a mess, and the raw string literals proposal only makes it worse.

Unicode escapes are processed in Java not just inside string literals, but everywhere in the source code. So, for example, the following program prints "Hello, world!" even though that line of code seems to be commented (\u000a is new line, so it ends the comment):

    public class Test {
      public static void main(String[] args) {
        // \u000a System.out.println("Hello, world!");
      }
    }
Moreover, a \u000a inside a string literal is the same as an actual newline, so the compiler doesn't accept it:

      Test2.java:3: error: unclosed string literal
        String s = "\u000a";
                          ^
But now with the raw string literal proposal, JEP 326[1], Unicode escape processing is disabled inside raw string literals, and \u0060 escapes (backticks) aren't considered backticks for the purposes of starting raw string literals.

So, with this proposal, Unicode escapes are in a worst-of-two-worlds middle way:

1) They can't be handled uniformly at a low level anymore, so a Java parser can't naively convert escapes while reading the source file, but

2) They must still be naively interpreted in unexpected places like comments and normal string literals, as shown in my examples.

What a mess.

[1] https://openjdk.java.net/jeps/326

Re: Raw String Literals Removed From Java 12 as Feature Set Frozen

#6

Post by maxxxxx »

mabbo wrote: post #2

JEP325 seems like a nice little improvement. Just a linguistic trick but still lovely. int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; }; Switches can return values, and can have multiple cases on the same line. I'm sure in 2 years when my organization gets around to switching to Java 12, I'll enjoy using it.

What happens if the value is not found? I would love it if you could throw an exception from a default block.

Re: Raw String Literals Removed From Java 12 as Feature Set Frozen

#7

Post by ccleve »

I'm glad they're going to try to get multi-line strings right, but seriously, I (and many other people) have wanted this feature for 19 years.

This is not an exaggeration. I was writing code in Java to access SQL databases in 1999 and needed it to express long SQL strings.

One would think they could move a little faster.

Re: Raw String Literals Removed From Java 12 as Feature Set Frozen

#8

Post by emidln »

ccleve wrote: post #7

I'm glad they're going to try to get multi-line strings right, but seriously, I (and many other people) have wanted this feature for 19 years. This is not an exaggeration. I was writing code in Java to access SQL databases in 1999 and needed it to express long SQL strings. One would think they could move a little faster.

I don't think I've ever wanted SQL embedded in my Java source over loading it as a resource. Loading it as a resource allows me to edit the SQL in a sql-aware text editor.

Re: Raw String Literals Removed From Java 12 as Feature Set Frozen

#10

Post by stickfigure »

emidln wrote: post #8
ccleve wrote: post #7

I'm glad they're going to try to get multi-line strings right, but seriously, I (and many other people) have wanted this feature for 19 years. This is not an exaggeration. I was writing code in Java to access SQL databases in 1999 and needed it to express long SQL strings. One would think they could move a little faster.

I don't think I've ever wanted SQL embedded in my Java source over loading it as a resource. Loading it as a resource allows me to edit the SQL in a sql-aware text editor.

IntelliJ is aware of SQL in text strings, and even validates it against the database schema.

I like my SQL right next to the code that sets parameters, processes results, etc - mismatches are apparent (and also validated by IntelliJ).

Post reply on HN