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

41–50 of 60 posts

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

#41

Post by userbinator »

teraflop wrote: post #39
userbinator wrote: post #32

Earlier quoted context omitted.

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 \uu…

The designers of Java wanted to support arbitrary Unicode characters in source code -- not just in string literals, but in identifiers as well.

In my experience (although not with Java; maybe its users would make more use of the feature, but I doubt it) even developers whose native language is not English but something very different like Chinese or Japanese will continue to use ASCII-only identifiers, and only write things like string constants or comments in their native language (which may mean using high bytes and a non-UTF8 multibyte encoding.) What the identifiers mean may be Romanised foreign words, but they're still written with [A-Za-z0-9_].

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

#42

Post by elygre »

yrro wrote: post #17
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…

Dear God Why did they do it like this Just why

Why did they do what?

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

#43

Post by paulddraper »

mruts wrote: post #20
paulddraper wrote: post #12

Earlier quoted context omitted.

Is it? I've used Scala before. There are some cases, like compilers where I could see matching and extracting complex and nested patterns to be useful. But in most cases monadic operations/functors plus if/else seems pretty much as good.

Unfortunately monads aren’t in base scala (as an explicit class at least), so often you need to do some ad-hoc pattern matching on tuples or data structures and pattern matching really helps in de-structuring and binding relevant variables. I probably use monadic operations (map, fold, etc) at least 5-10 times a day in my job (I’m a scala dev), and match expressions at least 3-5 times a day. So pretty useful I’d say.…

> Unfortunately monads aren’t in base scala (as an explicit class at least)

Scalaz and cats are perhaps the most common dependencies in the Scala ecosystem.

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

#45

Post by vbezhenar »

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.

That's a real problem that I've encountered. There were three web services which I consumed. They used a lot of classes with the same name and I had to work with them from one class. I had to use fully qualified names everywhere. At one point I rewrote this code using Kotlin. Kotlin had this feature, you could write "import com.package.foo.bar" and you could use "bar.Something" in your code. My code was sane. But in some release they decided to remove that feature for some reason.

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

#46

Post by jackewiehose »

teraflop wrote: post #39
userbinator wrote: post #32

Earlier quoted context omitted.

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 \uu…

> The designers of Java wanted to support arbitrary Unicode characters in source code -- not just in string literals, but in identifiers as well

That's bad! I recently noticed "my" C++ compiler allows you to write something like int mäin(){}. I didn't try it out but I guess it breaks with different file encodings.

Please stay with ASCII!

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

#47

Post by zapzupnz »

chrisseaton wrote: post #24
sebazzz wrote: post #19

Earlier quoted context omitted.

What is the reason for Unicode escapes? It is something legacy from when Unicode was not universally accepted in all systems? Do other programming languages have this?

Several programming languages have arcane ways to write what today seem like very normal characters. https://en.wikipedia.org/wiki/Digraphs_and_trigraphs For example C has escape sequences for characters as basic as # and [.

Doesn't it have escape sequences for those because they're used in the language's syntax? Stands to reason, or is this even in string literals?

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

#48

Post by teraflop »

userbinator wrote: post #41
teraflop wrote: post #39

Earlier quoted context omitted.

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 \uu…

The designers of Java wanted to support arbitrary Unicode characters in source code -- not just in string literals, but in identifiers as well. In my experience (although not with Java; maybe its users would make more use of the feature, but I doubt it) even developers whose native language is not English but something very different like Chinese or Japanese will continue to use ASCII-only identifiers, and only write…

Sure, but this was in the 1990s, when "internationalization" was The Next Big Thing.

At the time, the Java team really didn't have any way of knowing for sure whether or not non-ASCII source code would catch on, because most existing languages didn't support it.

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

#49

Post by ptx »

vbezhenar wrote: post #45
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.

That's a real problem that I've encountered. There were three web services which I consumed. They used a lot of classes with the same name and I had to work with them from one class. I had to use fully qualified names everywhere. At one point I rewrote this code using Kotlin. Kotlin had this feature, you could write "import com.package.foo.bar" and you could use "bar.Something" in your code. My code was sane. But in…

You can still write

  import com.package.foo.bar.Something as barSomething
according to the documentation: https://kotlinlang.org/docs/reference/packages.html

Although you'd have to do it for each class, so importing the whole package with an alias would be nice.

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

#50

Post by klodolph »

zapzupnz wrote: post #47
chrisseaton wrote: post #24

Earlier quoted context omitted.

Several programming languages have arcane ways to write what today seem like very normal characters. https://en.wikipedia.org/wiki/Digraphs_and_trigraphs For example C has escape sequences for characters as basic as # and [.

Doesn't it have escape sequences for those because they're used in the language's syntax? Stands to reason, or is this even in string literals?

They are alternative ways of writing the same character, unlike escape sequences, which have a different meaning from the unescaped version of the same character.

For example, in C, I can write:

    int a;
Or I can write:

    int a[10];
They are the same, because is exactly the same as ] (except… mercifully, digraphs are not interpreted in strings; trigraphs are another story). However, in a string, the escape sequence \" means something different from ". One is a character in the string, the other ends the string.

Digraphs and trigraphs exist because not all keyboards have the corresponding characters, like [ and ]. For example, look at a Swedish keyboard. (You can type [ and ], but not as easily, and maybe not at all on some older keyboards.)

Post reply on HN