Комментарии 14
НЛО прилетело и опубликовало эту надпись здесь
С другой стороны, из-за острой необходимости в обратной бинарной совместимости для EE такая тенденция может привести к созданию кучи избыточных API с дублирующейся функциональностью…
> бинарной совместимости
Необходимость не в бинарной, а в API совместимости. Бинарная совместимость на уровне байт-кода JVM.
Необходимость не в бинарной, а в API совместимости. Бинарная совместимость на уровне байт-кода JVM.
Когда писал «бинарная», я имел ввиду, что JVM не будет находить поля с нужными сигнатурами и будет падать с ошибками типа
java.lang.IncompatibleClassChangeError. Ну а что касается байт-кода, в новой версии class file была введена, например, инструкция invokedynamic и там действительно никакой обратной совместимости нет.НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я не вникал глубоко в статью, но если Context реализует Builder pattern для Producer, то вывод очевиден.
Хотя, при написании этого комментария, ко мне пришла очевидная мысль что Builder включает использование fluent interface, просто в конечном итоге вызывается еще один метод, который выполняет функцию «создай мне объект с этими настройками».
Хотя, при написании этого комментария, ко мне пришла очевидная мысль что Builder включает использование fluent interface, просто в конечном итоге вызывается еще один метод, который выполняет функцию «создай мне объект с этими настройками».
Пройдет еще лет этак 5-7, прежде чем это появится в коммерческих серверах приложений у клиентов. Один вопрос остается непонятным — неужели существуют реальные задачи, где была бы острая необходимость в новом API, и которые не могут быть решены с уже существующим? Я не усмотрел никаких радикальных нововведений, кроме некой удобоваримости. Но уж коле пишете по jee, забудьте про эстетику.
Лично я стал был использовать где-то через год, когда на кошках всё проверится и оттестируется и баги утрясутся.
Острой необходимости в новом API действительно нет, но согласитесь, что использовать его приятнее. Мы недавно на работе перешли на JavaSE7. Мелочи, вроде, а всё же я получаю удовольствие, когда применяю try с ресурсами и diamond notation радует. А когда multicatch удается использовать там, где раньше пришлось бы код в разных блоках обрабатывать, так вообще песня.
Мне кажется, что именно из этих мелочей складывается впечатление о языке. Не будь этого стремления к упращению, автоматиции, программировали бы все сейчас на узелках
Острой необходимости в новом API действительно нет, но согласитесь, что использовать его приятнее. Мы недавно на работе перешли на JavaSE7. Мелочи, вроде, а всё же я получаю удовольствие, когда применяю try с ресурсами и diamond notation радует. А когда multicatch удается использовать там, где раньше пришлось бы код в разных блоках обрабатывать, так вообще песня.
Мне кажется, что именно из этих мелочей складывается впечатление о языке. Не будь этого стремления к упращению, автоматиции, программировали бы все сейчас на узелках
Дело в том, что цикл обновления коммерческих серверов апликаций жутко медленный. До сих пор еще ни один из моих клиентов не использует сервер с JEE6: везде это либо WAS 7, WL 10 или JBoss 5. И мигрировать на новый профайл никто особо не собирается. Так что пока еще JEE7 увидит свет, пока на него мигрируют продукты и компоненты, пока это все смогут задвинуть клиенту — пройдут годы.
По поводу упрощения не согласен. JEE — это изначально неправильная и неудобоваримая вещь, далекая от реальных нужд и задач. Переход на аннотации отодвинули его смерть. То, куда стоит двигать JEE — это в сторону embedded runtime с программной конфигурацией, так, чтобы он больше смахивал на фреймворк, нежели на сервер. А шлифование API — это дело десятое.
По поводу упрощения не согласен. JEE — это изначально неправильная и неудобоваримая вещь, далекая от реальных нужд и задач. Переход на аннотации отодвинули его смерть. То, куда стоит двигать JEE — это в сторону embedded runtime с программной конфигурацией, так, чтобы он больше смахивал на фреймворк, нежели на сервер. А шлифование API — это дело десятое.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с JMS 2.0