Почему для try-with-resource требуется локальная переменная?

Ссылка в комментарии @McDowell показывает правильный ответ в комментарии к записи блога Джо Дарси, который руководил Спецификацией технологии Java, которая представила - заявление о ресурсах:

Вернувшись в JDK 7, мы начали с конструкции try-with-resources, подобной той, которая позволяла использовать общее выражение для ресурса, включая вызов метода. Тем не менее, группа экспертов, обнаруженная в ходе предварительного обзора проекта (http://jcp.org/aboutJava/communityprocess/edr/jsr334/index.html), что

«Возможное будущее изменение [в statemenbt try-with-resources] - это отказ от поддержки ресурса, который должен быть указан как общее Выражение. Нетривиальная спецификация и сложности реализации возникают из-за того, что общее Выражение может использоваться в качестве ресурса. Ограниченное выражение, которое может быть идентификатором или может быть достаточно PrimaryNoNewArray.Даже более строгое ограничение простого разрешения идентификатора может обеспечить почти всю дополнительную полезность разрешения полного выражения (по сравнению с принудительным объявлением новой переменной ресурса) при гораздо более низкой маргинальной реализации и влияние спецификации ".

К концу JDK 7 нам нужно было новое объявление переменной для ресурса или существующую конечную / фактически конечную переменную. У нас было время предоставить первое только в 7; в 9 мы также предоставляем последнее.

Среди вариантов использования, которые они рассматривали, большинству потребуется доступ к ресурсу внутри блока, например, открыть файл - файл для чтения / записи - закрыть файл. Они бы не приняли это дизайнерское решение, если бы думали, что существует множество случаев использования, когда локальная переменная не используется.

Что касается того, почему Lock не закрывается автоматически, я думаю, что Дуг Ли не слишком озабочен вопросом синтаксиса, он сосредоточен на решении сложной проблемы. Другие всегда могут добавить синтаксический сахар поверх своих утилит.

Забегая вперед, попробуйте-с-ресурсом, вероятно, выйдет из моды, его заменит лямбда. Например

lock.withLock( ()->{ execute-while-holding-the-lock; } );

Как бы мне ни хотелось, чтобы это было не так, логическое обоснование этого состоит в том, что try-with-resources предназначен исключительно для операций с элементом, который должен быть удален. Для этого требуется именованная переменная, потому что ожидается, что вы что-то сделаете с этой переменной, пока находитесь внутри блока. Я думаю, это как если бы компилятор сказал: «Если вы не планируете фактически использовать ресурс, почему вы пытаетесь использовать ресурсы?»

Теперь мы с вами прекрасно знаем, что мы не хотим на самом деле использовать ресурс: скорее, мы просто хотим убедиться, что он закрыт, когда мы закончим с ним, чтобы у нас не было разработчиков, которые постоянно блокируют систему. Но, как и многие другие вещи, им приходилось принимать дизайнерские решения, и, будучи в меньшинстве, мы не получали эту функцию.

Я думаю, что невозможность использовать локальную переменную послужила причиной для попытки с ресурсом.

До java 1.7 вам приходилось писать что-то вроде этого:

InputStream in = null;
try {
    in = ....;
} finally {
    if (in != null) {
        in.close();
    }
}

Здесь есть 2 минуса:

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

Синтаксис try-with-resource решает обе проблемы:

1. finally блок вообще не нужен.
2. Переменная ресурса остается доступной только в try блоке, т.е. там, где она должна быть известна.

Вот почему закрываемый ресурс должен быть локальным. В противном случае одним из основных недостатков синтаксиса try-with-resource является "отключение".