jep122
JDK 13于2019年9月17日发布时,它带有文本块作为预览功能。 那天,我们发表了蒂姆·佐勒(TimZöller)发表的一篇文章,介绍为什么文本块值得等待 。 现在看来,由于吉姆·拉斯基(Jim Laskey)撰写了新的Java增强提案JEP 368,用户似乎需要等待更长的时间才能看到文本块成为完整的功能,他还撰写了最初的提案,引入文本块作为预览。 JDK 13, JEP 355中的功能 。
JEP 368:文本块(第二预览)
那么,为什么会有文本块出现以进行第二次预览? 有很多开发人员热衷于取消预览功能,但是如果有什么值得做的事,那就值得做得很好。 文本块也是如此。 似乎有些开发人员在空白和换行控制方面苦苦挣扎。 在JEP 368的动机部分下,吉姆·拉斯基写道:
尽管如此,仍无法预测Java程序中每个字符串的作用。 仅仅因为一个字符串跨越源代码的多行并不意味着该字符串中需要换行符。 当将字符串放在多行上时,程序的一部分可能更具可读性,但是嵌入的换行符可能会更改程序另一部分的行为。 因此,如果开发人员可以精确控制换行符出现的位置,以及相关的问题,则可以在文本“块”的左侧和右侧显示多少空白会有所帮助。
JEP 368的第二轮预览希望通过添加两个新的转义序列来解决这些棘手的问题,这些转义序列管理显式的空白和换行控制。
还请参见:
新的转义序列
关于两个新的转义序列,JEP 368不得不说:
首先, \<line-terminator>
转义序列明确禁止插入换行符。
例如,通常的做法是将很长的字符串文字拆分为较小的子字符串的串联,然后将结果字符串表达式硬包装到多行中:
String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
"elit, sed do eiusmod tempor incididunt ut labore " +
"et dolore magna aliqua.";
使用\<line-terminator>
转义序列,可以表示为:
String text = """
Lorem ipsum dolor sit amet, consectetur adipiscing \
elit, sed do eiusmod tempor incididunt ut labore \
et dolore magna aliqua.\
""";
其次, \s
转义序列仅转换为一个空格( \u0020
)。
转义序列直到事件空间剥离后才翻译,因此\s
可以充当栅栏以防止剥离尾随空白。 在此示例中,在每行末尾使用\s
可以确保每行正好是六个字符长:
String colors = """
red \s
green\s
blue \s
""";
要删除还是不删除空格,这是一个问题
从JEP 355最后的变化是不是偶然的空白去除的替代标题下,它现在读取不删除附带的空白 :
如果Java引入了多行字符串文字,但不支持自动删除偶然的空格,那么许多开发人员会编写一种自己删除方法,或者游说String类包含删除方法。 但是,这意味着每次在运行时实例化字符串时都可能需要进行昂贵的计算,这将降低字符串插入的好处。 让Java语言强制删除开头和结尾位置的附带空白似乎是最合适的解决方案。 开发人员可以通过仔细放置结束定界符来选择不删除主要空白。
到目前为止,JEP 368尚未针对即将发布的JDK,但它的候选地位意味着它已被OpenJDK负责人接受并纳入路线图。 仍有时间针对JDK 14。
您可以在这里看到JEP 368的所有荣耀 。
翻译自: https://jaxenter.com/jep-368-text-blocks-second-preview-163817.html
jep122