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

Question

Со ссылкой на мой вопрос Any risk in a AutoCloseable wrapper for java.util.concurrent.locks.Lock?, мне интересно, почему для trh try-with-resource требуется локальная переменная с именем.

Мое текущее использование выглядит следующим образом:

try (AutoCloseableReentrantReadWiteLock.Lock l = _lock.writeLock()) { 
    // do something 
}   

Переменная l не используется внутри блока попытки и только загрязняет пространство имен. Из того, что я помню, аналогичный оператор C#using не требует локальной именованной переменной.

Есть ли причина, по которой невозможно было поддерживать следующее: с анонимной локальной переменной, которая закрыта в конце блока try?

try (_lock.writeLock()) { 
    // do something 
}   

Answer 1

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

До Java 1.7 вы должны были написать что-то вроде этого:

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

Есть 2 недостатков здесь:

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

Try-с-ресурса синтаксис решает обе проблемы:

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

Ссылка на комментарий по @McDowell показывает правильный ответ в a blog post comment Джо Дарси, который привел the Java Technology Specification, что ввел примерочных с-ресурсов заявление:

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

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

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