Почему методы translateEscapes и stripIndent String были включены в функцию текстового блока в Java 15?

Question

В Java 15 JEP 378: Text Blocks добавил три метода экземпляра: stripIndent(), translateEscapes(), и formatted(Object... args):

Следующие методы будут добавлены для поддержки текстовых блоков;

• String::stripIndent(): используется для удаления случайных пробелов из содержимого текстового блока
• String::translateEscapes(): используется для перевода escape-последовательностей
• String::formatted(Object... args): упростить подстановку значений в текстовом блоке

Полезность formatted при работе с текстовыми блоками объясняется в JEP, поэтому его наличие имеет для меня смысл.

Однако два других метода не кажутся особенно полезными для разработчика, работающего с текстовыми блоками. Как удаление отступов, так и escape-трансляция - это те вещи, которые автоматически обрабатываются компилятором в отношении текстовых блоков. Создателю кода никогда не нужно программно удалять отступы из текстового блока Java или переводить escape-символы в текстовом блоке. Кроме того, escape-преобразование было в компиляторе Java с момента его первоначального выпуска, поэтому, кроме двух новых escape-последовательностей, добавленных для поддержки текстовых блоков ( \s и \<line-terminator>), это даже не новая функция Java.

JEP объясняет, что методы доступны для доступа разработчиков, но не причину этого решения.

Алгоритм повторного отступа будет нормативным в Спецификации языка Java . Разработчики будут иметь к нему доступ через String::stripIndent, новый метод экземпляра.

Разработчики смогут избежать обработки через String::translateEscapes, новый метод экземпляра.

Почему эти методы были добавлены в паблик String API вместе с текстовыми блоками в Java 15, когда они бесполезны для управления текстовыми блоками вне компилятора (или кода, который в противном случае считывает исходный код Java)?

Я не вижу объяснения этого в JEP, поэтому мне интересно, есть ли какое-либо официальное слово или обсуждение, объясняющее включение этих методов в общедоступный API.

Answer 1

Я провел онлайн-поиск в списках рассылки JDK, средствах отслеживания ошибок и т. д. Я не нашел сообщения, полностью объясняющего мыслительный процесс, стоящий за решением.

Однако я нашел следующий комментарий в системе ошибок JDK Брайана Гетца, архитектора языка Java в Oracle (выделение добавлено мной):

Я полагаю, что проблема здесь заключается в том, что метод попал в следующие тиски: естественная семантика языка включает в себя удаление с обеих сторон, и мы хотим иметь библиотечный метод, который делает то, что делает язык (так что пользователям не нужно воссоздайте эту функциональность) , но поведение потенциально может удивить, если вы не устанавливаете связь с поведением языка. И очевидное решение — разделить точки входа; разрешить что-то вроде indent()чтобы охватить вариант использования «повторить только слева», который, по мнению Джо, является естественной интерпретацией для пользователей библиотеки, оставив stripIndent()как есть (возможно, с некоторыми переименованиями, чтобы лучше связать его с языковой функцией.)

Похоже, разработчики языка и API хотят, чтобы логика, используемая языком, была доступна разработчикам. Это не объясняет полностью, почему они считают, что это может быть полезно для пользователей API, но, по крайней мере, частично объясняет решение включить его.