1

在 Java 15 中，JEP 378: Text Blocks将三个实例方法添加到String: stripIndent()、translateEscapes()和formatted(Object... args):

将添加以下方法以支持文本块；

  • String::stripIndent()：用于从文本块内容中去除偶然的空白
  • String::translateEscapes(): 用于翻译转义序列
  • String::formatted(Object... args): 简化文本块中的值替换

JEP 中解释了使用文本块时的用处formatted，所以它的存在对我来说很有意义。

然而，其他两种方法对于使用文本块的开发人员来说似乎并不是特别有用。缩进剥离和转义翻译都是编译器针对文本块自动处理的事情。代码编写者永远不需要以编程方式从 Java 文本块中去除缩进，也不需要翻译文本块中的转义。此外，转义翻译自 Java 编译器最初发布以来一直存在，因此除了添加两个新的转义序列以支持文本块（\s和\<line-terminator>）之外，它甚至不是 Java 的新功能。

JEP 解释说这些方法可供开发人员访问，但不是做出此决定的原因。

重新缩进算法将在The Java Language Specification中成为规范。String::stripIndent开发人员将可以通过一个新的实例方法来访问它。

String::translateEscapes开发人员将可以通过一个新的实例方法访问转义处理。

为什么这些方法String与 Java 15 中的文本块一起添加到公共 API 中，而它们对于在编译器之外操作文本块（或以其他方式读取 Java 源代码的代码）没有用处？

我没有在 JEP 中看到它的解释，所以我想知道是否有任何官方文字或讨论来解释将这些方法包含在公共 API 中。

4

1 回答 1

1

我已经对 JDK 邮件列表、错误跟踪器等进行了一些在线搜索。我还没有找到完全解释决策背后的思考过程的帖子。

然而，我确实在 Oracle 的 Java 语言架构师 Brian Goetz 的 JDK Bug System 中找到了以下评论（重点由我添加）：

我相信这里的张力在于该stripIndent()方法陷入了以下虎钳：语言的自然语义包括两边的剥离，我们希望有一个库方法来做语言所做的事情（所以用户不必重新创建该功能)，但是stripIndent()如果您不与语言行为建立联系，则 的行为可能会令人惊讶。显而易见的解决方案是拆分入口点；允许类似indent()覆盖“仅从左侧重新缩进”用例，Joe 认为这是图书馆用户的自然解释，同时保持stripIndent()原样（可能进行一些重命名以更好地将其与语言功能联系起来。）

似乎语言和 API 设计人员希望开发人员可以使用该语言使用的逻辑。这并没有完全解释为什么他们认为它可能对 API 的用户有用，但它至少部分解释了包含它的决定。

于 2021-12-24T07:04:26.650 回答