JEP proposed to drop from JDK 12: 326: Raw String Literals (Preview)
brian.goetz at oracle.com
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 oracle.com 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 
> 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
>  I’ll drop this JEP from JDK 12.
> - Mark
>  https://openjdk.java.net/census#jdk
>  https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
More information about the jdk-dev