JEP proposed to drop from JDK 12: 326: Raw String Literals (Preview)

Brian Goetz brian.goetz at
Tue Dec 11 17:20:38 UTC 2018

Some background rationale on this.

The Preview Feature mechanism is intended for features for which there 
is a high confidence that the feature is "done", and the likelihood that 
significant changes would be made before making the feature permanent is 
low.  At this time, and after extensive consideration, Jim and I no 
longer believe this to be the case, and we think letting it preview in 
its current state would be to the detriment of the language.  We're of 
course disappointed that this means it will take slightly longer for 
this feature to make it into the language, but we think that's the best 

While we can expect that for any language feature, there will be a 
nontrivial volume of "I would have preferred it differently" feedback, 
in reviewing the feedback we have received, I am no longer convinced 
that we've yet got to the right set of tradeoffs between complexity and 
expressiveness, or that we've explored enough of the design space to be 
confident that the current design is the best we can do.  By 
withdrawing, we can continue to refine the design, explore more options, 
and aim for a preview that actually meets the requirements of the 
Preview Feature process (JEP 12).

For the record, here is some of the feedback we've received on the 
design.  These are incomplete and in no particular order (and some of 
them are likely not fixable but may be worth exploring further anyway).

  - The two-backquote sequence `` could be confused for an empty string, 
but in fact is an opening delimiter.

  - There is no directway to start or end a raw string literal with a 

  - Raw string literals can be multi-line, but traditional string 
literals cannot. (Alternately, multi-line string literals MUST also be 
raw, which isn't always what the user wants.) This is an unnecessary 
asymmetry, given that these properties are logically independent, and 
such asymmetries generally increase the cognitive load on the user.

  - We have relatively few unused punctuation characters left, and using 
backquote for RSLs may be excessively profligate.  Further, using 
another quote character for raw string literals (rather than a prefix, 
modifier, embedded sequence, or similar mechanism) leaves us in a tight 
spot if we discover the need for a third kind of string literal.  We've 
not sufficiently explored alternatives that would let us avoid burning 
one of the few remaining characters we have.

  - The backquote character is somewhat typographically lightweight; it 
is easy to miss, and could therefore cause confusion over where a large 
string ends and the containing code resumes.

  - The "any number of quotes" rule can confuse IDEs over whether a 
sequence of quotes is open-contents-close, or a large opening delimiter, 
limiting their ability to help by filling in closing delimiters and 
placing the caret in the right place.  We want Java to remain one of the 
most tool-friendly languages.

  - While it's cool that we can embed a seventeen-quote run in an 
eighteen-quoted string, such strings can also get pretty hard to read.

We think we can do better on some or many of these fronts.  One of the 
benefits of the newer more rapid cadence is that the cost of missing a 
train (even one that you have already boarded, but which has not yet 
left the station) is much lower.  And, assuming that it is unlikely that 
we'd exit Preview unchanged, withdrawing now does not change the likely 
date at which this feature becomes permanent, as we'd likely want to 
re-Preview a modified version anyway.

Discussion on the technical details of this feature can continue to take 
place on the amber-* lists.

On 12/11/2018 12:13 PM, mark.reinhold at wrote:
> The owner of this JEP has proposed to drop it from JDK 12:
>    326: Raw String Literals (Preview)
> The rationale for this proposal will follow in a moment.
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:00 UTC on Tuesday, 18 December, or if they’re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I’ll drop this JEP from JDK 12.
> - Mark
> [1]
> [2]

More information about the jdk-dev mailing list