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

51–60 of 60 posts

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

#51

Post by aardvark179 »

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…

I have seen quite a lot of source in Japanese where the language allows it easily, much of it was written by a Japanese partner and their customers so it made sense for them.

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

#52

Post by aardvark179 »

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.

It’s only a preview feature in 12, so you need to give a command line switch to java for it to be enabled.

It’s also the first part of a much larger feature adding pattern matching to the Java language. Getting all the ducks in a row for this sort of thing is tricky because it touches so many other ares, but switch expressions can be delivered on their own quite nicely.

Adding patterns means looking at variable scopes (where is a variable bound in a pattern in scope?), record classes (because destructuring patterns should not be implemented by hand everywhere), and even constants and raw string literals (because being able to switch on regexps would be nice, and you need a good way to write that).

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

#53

Post by aardvark179 »

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…

String substitution and raw string literals aren’t really that closely connected. I’d also suggest that if string substitution becomes nice it will get used far more, so it needs to be implemented in a way that constant folds things nicely. So if I had to guess it might get looked at after the work being done on constants.

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

#54

Post by userbinator »

jackewiehose wrote: post #46
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 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!

Due to how they were written, a lot of compilers don't really care about character encoding in the sense that any bytes >127 were simply considered identifier characters because their tokenisers picked out the special characters and "anything else" would be classified with the usual identifier range. This meant you could use whatever single or multibyte encodings you wanted, as long as any trailing bytes of a single character didn't conflict with the special characters; with this, UTF-8 naturally works too.

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

#55

Post by bitmapbrother »

dang wrote: post #37
Go0the0gophers wrote: post #30

Bye bye Java, still time to switch to real language (e.g Go)

Could you please stop posting unsubstantive comments to Hacker News?

Or what? You're going to shadow ban him like you do with the rest of the people you disagree with?

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

#56

Post by mabbo »

aardvark179 wrote: post #52
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.

It’s only a preview feature in 12, so you need to give a command line switch to java for it to be enabled. It’s also the first part of a much larger feature adding pattern matching to the Java language. Getting all the ducks in a row for this sort of thing is tricky because it touches so many other ares, but switch expressions can be delivered on their own quite nicely. Adding patterns means looking at variable scope…

That sounds lovely. Fully functional pattern matching in Java would be a godsend.

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

#57

Post by halfastack »

idontpost wrote: post #36
hyperman1 wrote: post #28

Earlier quoted context omitted.

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.

I have difficulty seeing what this would add. As a Java developer, I know what "List" is, just like I know what "ArrayList" is. If someone instantiated new better.ArrayList(), I immediately have to check what the hell is the import (go to the top of the class, uncollapse the import statements, and see what is "better").

As with all code readability, I assume to write and use import aliases, that's very easy. The person who's gonna read it after you, they've got a problem. And that's why I'd personally be strongly against this in my code review.

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

#58

Post by Polyisoprene »

mruts wrote: post #11

If Java were to support to scale/fp-like match statements with case objects and unapply methods, it would probably be good enough to obviate Scala (It would still be distinctly worse though). Pattern matching is such a powerful feature. I wish more languages (like python) would realize it’s value and add it.

Hopefully project Amber will arrive soon.

https://cr.openjdk.java.net/~briangoetz/amber/pattern-match....

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

#59

Post by ptx »

halfastack wrote: post #57
idontpost wrote: post #36

Earlier quoted context omitted.

> 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.

I have difficulty seeing what this would add. As a Java developer, I know what "List" is, just like I know what "ArrayList" is. If someone instantiated new better.ArrayList(), I immediately have to check what the hell is the import (go to the top of the class, uncollapse the import statements, and see what is "better"). As with all code readability, I assume to write and use import aliases, that's very easy. The pers…

> As a Java developer, I know what "List" is

Is that java.awt.List or java.util.List?

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

#60

Post by idontpost »

halfastack wrote: post #57
idontpost wrote: post #36

Earlier quoted context omitted.

> 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.

I have difficulty seeing what this would add. As a Java developer, I know what "List" is, just like I know what "ArrayList" is. If someone instantiated new better.ArrayList(), I immediately have to check what the hell is the import (go to the top of the class, uncollapse the import statements, and see what is "better"). As with all code readability, I assume to write and use import aliases, that's very easy. The pers…

Using the example from your other reply:

import java.awt.List as awtList

import java.util.List as utilList

Granted, there's not a lot of scenarios where you have this sort of collision, but it does happen and using aliasing makes the code easier to read.

Post reply on HN