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

31–40 of 60 posts

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

#31

Post by QuercusMax »

jfim wrote: post #25
beders wrote: post #15

Adding new syntax to Java is tricky (unless certain other JVM languages starting with C ;) but I was really disappointed in the string proposal. At the very least, have a default, optional string substitution feature. It ain't that hard and it's something users of raw strings will NEED anyways. What good is it to have snippets of raw strings that then need to be parsed again and split and re-glued again? JavaScript b…

> unless certain other JVM languages starting with C Are you referring to Clojure or Ceylon? Or both, or neither?

Kotlin?

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

#32

Post by userbinator »

moefh wrote: post #5

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[] ar…

not just inside string literals

This is the most unusual part and just leaves me asking why!?!? Was it an error of omission, or a deliberate design decision, to essentially preprocess the whole file blindly with Unicode escape parsing instead of putting it only inside the string literal (and character constant) parser like just about every other language that has a similar escape system? The fact that \n behaves differently (and in the sane manner that those are accustomed to from C/C++) is the most bizarre part --- Unicode escaped could've been handled by the same parser, but they didn't.

Sibling comments mention trigraphs. Those are different, starting with ?? instead of \, so their "applicable to the whole file" behaviour is more reasonable. But \-escapes are, outside of preprocessor line continuations (where it's literally \ followed by a newline), customarily only interpreted inside character and string constants.

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

#33

Post by cogman10 »

helfire wrote: post #4
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.

This is mostly due to Java 9 breaking everything.

Post Java 11, I doubt you will see the same problems you did with going from 8 to 9 or 11

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

#34

Post by needusername »

vmsp wrote: post #9

Can anyone recommend a good resource to get up to speed with Java's new features since 1.8?

I find the JEPs listed on the individual project pages quite helpful

- https://openjdk.java.net/projects/jdk9/

- https://openjdk.java.net/projects/jdk/10/

- https://openjdk.java.net/projects/jdk/11/

- https://openjdk.java.net/projects/jdk/12/

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

#35

Post by wbl »

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.

Introduced for the first time in Algo 68 as far as I know.

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

#36

Post by idontpost »

hyperman1 wrote: post #28
jorblumesea wrote: post #22

Can someone explain to me why java has never considered as "import com.package.foo.bar as bar" feature? I really think fully qualified names can be disgusting when you have two classes of the same name.

I assume it is because Java developers rely very heavily on their IDEs. Most of these IDEs simply hide the import statements by default. So you assume the imports are irrelevant, unless explicitly spelled out - and clashes are rare enough to not be much of a problem in practice. If imports are renamed, you would have to actually care about the import statements.

> If imports are renamed, you would have to actually care about the import statements.

Not really. VS Code transparently handles aliasing of imports in JS. You still never need to look at them manually AND you get the benefit of cleaner naming.

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

#38

Post by kvakil »

jfim wrote: post #25
beders wrote: post #15

Adding new syntax to Java is tricky (unless certain other JVM languages starting with C ;) but I was really disappointed in the string proposal. At the very least, have a default, optional string substitution feature. It ain't that hard and it's something users of raw strings will NEED anyways. What good is it to have snippets of raw strings that then need to be parsed again and split and re-glued again? JavaScript b…

> unless certain other JVM languages starting with C Are you referring to Clojure or Ceylon? Or both, or neither?

I believe they're almost certainly referring to Clojure macros

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

#39

Post by teraflop »

userbinator wrote: post #32
moefh wrote: post #5

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[] ar…

not just inside string literals This is the most unusual part and just leaves me asking why!?!? Was it an error of omission, or a deliberate design decision, to essentially preprocess the whole file blindly with Unicode escape parsing instead of putting it only inside the string literal (and character constant) parser like just about every other language that has a similar escape system? The fact that \n behaves diff…

It was a deliberate decision. The Java language specification [1] says:

> The Java programming language specifies a standard way of transforming a program written in Unicode into ASCII that changes a program into a form that can be processed by ASCII-based tools. The transformation involves converting any Unicode escapes in the source text of the program to ASCII by adding an extra u - for example, \uxxxx becomes \uuxxxx - while simultaneously converting non-ASCII characters in the source text to Unicode escapes containing a single u each.

The Java language grammar is defined in terms of Unicode, but it was designed in the early days before Unicode was ubiquitous. In particular, this was long before UTF-8 took its current place as the de facto standard character encoding.

The designers of Java wanted to support arbitrary Unicode characters in source code -- not just in string literals, but in identifiers as well. But they also wanted to preserve interoperability between systems using different character encodings.

It's certainly confusing that \u behaves differently from other backslash escape sequences, but I guess they figured that was less bad than introducing an entirely new escape character.

[1]: https://docs.oracle.com/javase/specs/jls/se11/html/jls-3.htm...

Post reply on HN