Draft JEP: Raw String Literals

Stuart Marks stuart.marks at oracle.com
Tue Jan 30 00:51:46 UTC 2018

On 1/27/18 6:43 AM, Jim Laskey wrote:
> The time has come to revisit strings in terms of the modern development world. “Java remains one of a small group of contemporary programming languages that do not provide language-level support for raw strings.”
> This JEP proposes the introduction of Raw String Literals into the Java Language.
> https://bugs.openjdk.java.net/browse/JDK-8196004 <https://bugs.openjdk.java.net/browse/JDK-8196004>

Nicely written, and this facility is certainly needed.

Regarding the choice of delimiter, I suspect this is one of those things where 
there are multiple camps that all disagree with each other. No matter which one 
you choose (and yes, you should choose one) the others are going to complain.


I think the senses of the escape() and unescape() library calls are backwards as 
proposed. To me, "escaping" something means replacing some data with an 
alternative form -- an escape sequence -- that can be dealt with more 
conveniently, e.g. that can be typed on a keyboard, and that is visible on a 
printout. For example, consider a string that contains

     U+000A LINE FEED

"Escaping" this string means turning this control character into a sequence of 
printable, typable characters:


(that is, \ followed by n).

And "unescaping" is the opposite, to remove escape sequences from a string by 
replacing them with the character data they represent.

Both of the following would be true:


And, if the mailer doesn't screw up the spacing, the expressions below are 
equivalent to those above, and both would also be true:




Thus, we have escape() defined as "to process a string into escape sequences" 
and unescape() defined as "to remove escape sequences by replacing them with the 
character data they represent". I haven't been able to find anything definitive 
that supports this sense, but it does seem to agree with common parlance (e.g., 
blog posts, Stack Overflow questions).

The proposal currently has escape() meaning "to process escape sequences into 
original character data" which is sort of sensible. But then unescape() means to 
*add* escape sequences, which seems very odd. For that reason I prefer the 
opposite senses.



More information about the amber-dev mailing list