Как стать автором
Обновить

Комментарии 35

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Убрал.
НЛО прилетело и опубликовало эту надпись здесь
>должно быть созданием ресурса, тип которого является подтипом AutoCloseable.

Не обязательно созданием, можно и уже созданный ресурс передать.
Сделали бы они параметры по умолчанию, как в С++, цены бы им не было.
А так, прогресс все же радует, хоть и небольшой и затяжной. Не понятно только почему исключения объединяются через пайп, а не перечисляются через запятую.
Наверняка не могут из за обратной совместимости, как и многое другое
Да не, не должно быть тут логической совместимости, ибо новый код со старым не конфликтует.
Скорее всего, что бы читалось как «или», когда пробегаешь глазами код.
учите историю :)
параметры по умолчанию были в самой первой версии джавы
потом их оттуда осознанно убрали, читайте интервью автора джавы почему если интересно
а на русском есть?
Хорошо, но мало.
А что будет, если autoclose exception перезатрёт exception из блока catch? Вот ведь основная проблема с try/finally/close. Сколько времени было убито лично мной изза этой проблемы…
Т.к. новый код обратно совместим со старым и, по сути, от него не отличается, то проблему надо решать так же, как она решалась ранее.
То есть обернуть вызов close в трай кетч, с дополнительной обработкой. Как это сделать в данном случае, где close() в явном виде нигде не написан?
гениально, если еще и printStackTrace будет наглядно такие вещи показывать, то проблема будет полностью снята.
Посмотрите там же на printStackTrace, он это поддерживает.
Спека раскрывает детали:
If the initialization of the resource completes abruptly because of a throw of a value V, or if the Block of the try-with-resources statement completes abruptly because of a throw of a value V and the automatic closing of the resource completes normally, then the try-with-resources statement completes abruptly because of the throw of value V.

If the Block of the try-with-resources statement completes abruptly because of a throw of a value V1, and the automatic closing of the resource completes abruptly because of a throw of a value V2, then the try-with-resources statement completes abruptly because of the throw of value V1 with V2 added to the suppressed exception list of V1.

In a try-with-resources statement that manages multiple resources:

If the initialization of a resource completes abruptly because of a throw of a value V, or if the Block of the try-with-resources statement completes abruptly because of a throw of a value V (which implies that the initialization of all resources completed normally) and the automatic closings of all initialized resources completes normally, then the try-with-resources statement completes abruptly because of the throw of value V.

If the initialization of a resource completes abruptly because of a throw of a value V1 and the automatic closings of one or more resources (that were previously successfully initialized) complete abruptly because of throws of values V2...Vn, then the try-with-resources statement completes abruptly because of the throw of a value V1 with V2...Vn added to the suppressed exception list of V1.

If the Block of the try-with-resources statement completes abruptly because of a throw of a value V1, and the automatic closings of one or more resources (that were previously successfully initialized) complete abruptly because of throws of values V2...Vn, then the try-with-resources statement completes abruptly because of the throw of a value V1 with V2...Vn added to the suppressed exception list of V1.

Переводить лениво — на хабре есть любители попереводить, сорри :)
Слишком долго разработчики Java обсуждают проблемы обратной совместимости и добавления нового функционала. Безусловно, не хотелось бы видеть язык Java чересчур перегруженным разного рода наворотами, но в то же время есть опасность оставаться без развития долгое время.
Мне если честно так не хватает этих плюшечек @AutoCloseable, но и без них вполне можно прожить — да кодить приходиться чуть более и только.
Java уже мощный инструмент не только благодаря своему синтаксису, но и окружению из спек и уймы доступных библиотек реализующих и покрывающих практически все нужды типичной задачи.
Улучшения самого языка безусловно принесут большую популярность, и сделают код прозрачнее, сделав написание такого кода удовольствием.

Было бы круто если бы улучшили performance(client jvm-jre) + ui libraries из коробки, то где java очень сильно пока проигрывает нативным библиотекам, и за что её не особо любят в desktop.
Полностью согласен насчёт перформанса, особенно в свете недавного ковыряния в настройках garbage collector-ов :)
Он мощный еще и потому что авторы так тщательно продумывают спеку, создают прочный и надежный фундамент. Иначе был бы через лет 5 такой хаос, что Гослинг бы застрелился

Если честно меня не особо радуют многие изменения, AutoCloseable явно плюс, switch по строкам красота, а вот несколько ексепшенов в блоке try выглядят ужасно, учитывая что в уме еще надо найти общий потомок и влепить уже третий класс в такой крошечный кусочек кода. Остальное, не более чем синтаксический сахар без особой пользы. но неоправданно нагружающий мозг как новичка при обучении, так и опытного, который предвкушает чтение такого кода
Люблю Java именно за этот минимализм. Нет ничего лишнего, но есть все необходимое.

Из C# постепенно «все в одном» делают: и запросы, и динамическая типизация, и ФП, и скрипты… Может кому и нравится — не знаю. Как по мне — так для каждой задачи нужно использовать более подходящую технологию, а не совмещать. Но это холивар, конечно.
минимализм в добавлении фич — пожалуйста
а вот то что зачастую нет минимализма в синтаксисе — это ужасно

те же <> почему нельзя было сразу ввести?
А аннотации типов будут?
Какой тип будет у переменной исключения, если в блоке catch перечислено несколько классов? Наименьший общий предок этих классов?
from draft spec: In the case of a multi-catch exception parameter, the least upper bound of the types in question always exists since the types of all the caught exceptions must be subclasses of Throwable. Therefore, Throwable is an upper bound of the types in question, but it may not be the least upper bound since some subclass of Throwable may be a superclass (and thereby also a supertype) of the types in question.

Вы правы будет самый низкий родитель в обоих иерархиях. Что кстати довольно логично, и очень приятно. Одно из усилений в данном случае final e:
The exception parameter of a multi-catch clause (catch (Exception1 | Exception2 e) {...}) is implicitly final.
Спасибо!
Ах добавьте пожалуйста добавьте:
The existing rules for the switch statement forbid a null label and require a NullPointerException to be thrown if the expression being switched on is null. A null expression can occur for both enum types and for boxed primitive types like Integer and Float. Therefore, consistency alone argues for these prohibitions to also be in place when switching on a string.

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

Со строками, конечно, будет помедленнее, но на то и голова чтоб в критических местах не применять конструкции, нацеленные на удобство использования :)
> Теперь можно не повторять определение типа при создании объекта generic класса
Может быть, правильнее написать типовые параметры?
Радует что сделали AutoCloseable\try, аналог IDisposable\using конструкции из .net\C#, удобная и хорошо читаемая конструкция.
У этой конструкции есть также такая не менее приятная особенность, как ограничение области видимости в пределах блока using.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.