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

Brian Goetz 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 choice.

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

 - 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) http://openjdk.java.net/jeps/326 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] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

More information about the jdk-dev mailing list