Знакомство с JMS 2.0

[@dannote]

С другой стороны, из-за острой необходимости в обратной бинарной совместимости для EE такая тенденция может привести к созданию кучи избыточных API с дублирующейся функциональностью…

[@Ganga]

> бинарной совместимости

Необходимость не в бинарной, а в API совместимости. Бинарная совместимость на уровне байт-кода JVM.

[@dannote]

Когда писал «бинарная», я имел ввиду, что JVM не будет находить поля с нужными сигнатурами и будет падать с ошибками типа java.lang.IncompatibleClassChangeError. Ну а что касается байт-кода, в новой версии class file была введена, например, инструкция invokedynamic и там действительно никакой обратной совместимости нет.

[@Ganga]

> привести к созданию кучи избыточных API с дублирующейся функциональностью

Из-за новых методов IncompatibleClassChangeError выпасть не может.

[@dannote]

А вот из-за отсутствия старых как раз может, о чем я изначально и писал :)

[@ngreduce]

Я не вникал глубоко в статью, но если Context реализует Builder pattern для Producer, то вывод очевиден.
Хотя, при написании этого комментария, ко мне пришла очевидная мысль что Builder включает использование fluent interface, просто в конечном итоге вызывается еще один метод, который выполняет функцию «создай мне объект с этими настройками».

[@Throwable]

Пройдет еще лет этак 5-7, прежде чем это появится в коммерческих серверах приложений у клиентов. Один вопрос остается непонятным — неужели существуют реальные задачи, где была бы острая необходимость в новом API, и которые не могут быть решены с уже существующим? Я не усмотрел никаких радикальных нововведений, кроме некой удобоваримости. Но уж коле пишете по jee, забудьте про эстетику.

[@shurik2533]

Лично я стал был использовать где-то через год, когда на кошках всё проверится и оттестируется и баги утрясутся.
Острой необходимости в новом API действительно нет, но согласитесь, что использовать его приятнее. Мы недавно на работе перешли на JavaSE7. Мелочи, вроде, а всё же я получаю удовольствие, когда применяю try с ресурсами и diamond notation радует. А когда multicatch удается использовать там, где раньше пришлось бы код в разных блоках обрабатывать, так вообще песня.
Мне кажется, что именно из этих мелочей складывается впечатление о языке. Не будь этого стремления к упращению, автоматиции, программировали бы все сейчас на узелках

[@Throwable]

Дело в том, что цикл обновления коммерческих серверов апликаций жутко медленный. До сих пор еще ни один из моих клиентов не использует сервер с JEE6: везде это либо WAS 7, WL 10 или JBoss 5. И мигрировать на новый профайл никто особо не собирается. Так что пока еще JEE7 увидит свет, пока на него мигрируют продукты и компоненты, пока это все смогут задвинуть клиенту — пройдут годы.

По поводу упрощения не согласен. JEE — это изначально неправильная и неудобоваримая вещь, далекая от реальных нужд и задач. Переход на аннотации отодвинули его смерть. То, куда стоит двигать JEE — это в сторону embedded runtime с программной конфигурацией, так, чтобы он больше смахивал на фреймворк, нежели на сервер. А шлифование API — это дело десятое.