JEP proposed to drop from JDK 12: 326: Raw String Literals (Preview)
scolebourne at joda.org
Tue Dec 11 20:00:07 UTC 2018
Thank you for reconsidering. I strongly support the delay.
On Tue, 11 Dec 2018 at 17:21, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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)
> > 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 
> > 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