Comments 35
UFO just landed and posted this here
Сделали бы они параметры по умолчанию, как в С++, цены бы им не было.
А так, прогресс все же радует, хоть и небольшой и затяжной. Не понятно только почему исключения объединяются через пайп, а не перечисляются через запятую.
А так, прогресс все же радует, хоть и небольшой и затяжной. Не понятно только почему исключения объединяются через пайп, а не перечисляются через запятую.
Хорошо, но мало.
А что будет, если autoclose exception перезатрёт exception из блока catch? Вот ведь основная проблема с try/finally/close. Сколько времени было убито лично мной изза этой проблемы…
Т.к. новый код обратно совместим со старым и, по сути, от него не отличается, то проблему надо решать так же, как она решалась ранее.
exception можно будет получить вот так:
download.java.net/jdk7/docs/api/java/lang/Throwable.html#getSuppressed%28%29
download.java.net/jdk7/docs/api/java/lang/Throwable.html#getSuppressed%28%29
Спека раскрывает детали:
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.
Переводить лениво — на хабре есть любители попереводить, сорри :)
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.
Java уже мощный инструмент не только благодаря своему синтаксису, но и окружению из спек и уймы доступных библиотек реализующих и покрывающих практически все нужды типичной задачи.
Улучшения самого языка безусловно принесут большую популярность, и сделают код прозрачнее, сделав написание такого кода удовольствием.
Было бы круто если бы улучшили performance(client jvm-jre) + ui libraries из коробки, то где java очень сильно пока проигрывает нативным библиотекам, и за что её не особо любят в desktop.
Полностью согласен насчёт перформанса, особенно в свете недавного ковыряния в настройках garbage collector-ов :)
Он мощный еще и потому что авторы так тщательно продумывают спеку, создают прочный и надежный фундамент. Иначе был бы через лет 5 такой хаос, что Гослинг бы застрелился
Если честно меня не особо радуют многие изменения, AutoCloseable явно плюс, switch по строкам красота, а вот несколько ексепшенов в блоке try выглядят ужасно, учитывая что в уме еще надо найти общий потомок и влепить уже третий класс в такой крошечный кусочек кода. Остальное, не более чем синтаксический сахар без особой пользы. но неоправданно нагружающий мозг как новичка при обучении, так и опытного, который предвкушает чтение такого кода
Если честно меня не особо радуют многие изменения, AutoCloseable явно плюс, switch по строкам красота, а вот несколько ексепшенов в блоке try выглядят ужасно, учитывая что в уме еще надо найти общий потомок и влепить уже третий класс в такой крошечный кусочек кода. Остальное, не более чем синтаксический сахар без особой пользы. но неоправданно нагружающий мозг как новичка при обучении, так и опытного, который предвкушает чтение такого кода
Люблю Java именно за этот минимализм. Нет ничего лишнего, но есть все необходимое.
Из C# постепенно «все в одном» делают: и запросы, и динамическая типизация, и ФП, и скрипты… Может кому и нравится — не знаю. Как по мне — так для каждой задачи нужно использовать более подходящую технологию, а не совмещать. Но это холивар, конечно.
Из 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.
Вы правы будет самый низкий родитель в обоих иерархиях. Что кстати довольно логично, и очень приятно. Одно из усилений в данном случае 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: лучше бы этого не было. хотя надеюсь реализация будет оптимальной.
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: лучше бы этого не было. хотя надеюсь реализация будет оптимальной.
java.sun.com/docs/books/jvms/second_edition/html/Compiling.doc.html#14942
по спеке все должно быть хорошо :)
Но вот как будет со строками? :)
по спеке все должно быть хорошо :)
Но вот как будет со строками? :)
> Теперь можно не повторять определение типа при создании объекта generic класса
Может быть, правильнее написать типовые параметры?
Может быть, правильнее написать типовые параметры?
Радует что сделали AutoCloseable\try, аналог IDisposable\using конструкции из .net\C#, удобная и хорошо читаемая конструкция.
Sign up to leave a comment.
Разбираем JSR-334: примеры кода