Вышел Spring Framework 3.1

Servelet

ктоэта?! :-D

и, по-моему, слово source лишнее в названии фреймворка.

Спасибо, обновился :-)

Отказ от XML всегда хорошо.

Не нужно.

Неподъемное угробище.

Лучше уж XML, чем высоченная стопка аннотаций над методом.

ктоэта?! :-D

Kolbasa

ну и хорошо, отличный framework :)

Лично мне удобнее аннотации.Меньше букв :) и бегать из одного файла в другой не требуется

Сегодня впервые употребил ЛОР как информационный ресурс и сменил 3.1.0.BUILD-SHAPSHOT на 3.1.0.RELEASE в своем pom.xml

Что довольно занимательно поскольку создавался в виде «нахрена вам этот неподъемный j2ee - легкий спринг то шо надо для тырпрайза».

Ага. EJB упростили, а Spring как был монстром так им и остался.

IMHO Управление транзакциями, DI, тестирование в Spring на много проще чем JEE. Плюс в Spring есть интеграция с популярными фреймворками что делает его ещё и gluecode помимо просто DI.

2:vada&r Чем Spring более громоздкий чем JEE? )))

Чем Spring более громоздкий чем JEE? )))

спеком Ж:)

Новая версия ненужно! Спешите видеть ненужно, в новой версии оно особенно ненужно! :)

Вы игнорируете этого ненужно.

спеком Ж:)

Вы случаем в Jboss или Oracle не работаете? Говорить, что spring тяжелый в сравнении с EJB и прочими EE это по меньшей мере странно.

Не прошло и двух лет...

Аннотации - такой же facepalm, как и XML с неймспейсами. Куда мир катится...

Поддержка Servlet 3.0 позволяющая полностью отказаться от XML файлов конфигурации;

«Making humans edit XML is sadistic!(c) Django туториал.

мы должны быть благодарны spring'у и адепту его Maxcom'у за LOR

«Making humans edit XML is sadistic!(c) Django туториал.

А программисты не человеки. Они инопланетяне, просто маскируются хорошо.

Дай Бог этому говно-фреймворку скорой и мучительной смерти.

Вы случаем в Jboss или Oracle не работаете? Говорить, что spring тяжелый в сравнении с EJB и прочими EE это по меньшей мере странно.

Не знаю, какой он по сравнению с EJB по размеру. Но то, что он крив, уродлив и глючен - 100%. Надо быть нереальным гением чтобы породить такую мерзкую химеру. Слава и почет Роду Джонсону и всем его последователям!

Ага. EJB упростили, а Spring как был монстром так им и остался.

А нахрена его делать легковесным, удобным и надежным? Тогда ведь никто не будет книжки про него покупать да на всякие семинары ходить. А ведь это - основной доход Spring Source.

не нужно с тех пор как появился java ee 6. Спринг нынче монстрообразный.
Давно сполз с спринга, чего и вам желаю.

Но то, что он крив, уродлив и глючен - 100%

а это вы зря. Лучше кода чем в исходниках спринга я не видел. По нему учился.

Код у спринга действительно хорош.
Но многооооо.......... :)

Но то, что он крив, уродлив и глючен - 100%

а это вы зря. Лучше кода чем в исходниках спринга я не видел. По нему учился.

Это типа шутка такая?

Последний раз смотрел на него три года назад. Впечатления такие: сам по себе код - на троечку. Многословно, неоправданно запутано. Но главная жесть не в этом: а) глючно б) кривой дизайн самого API. А раз дизайн убог и код глючен, то нафига нужна эта то-ли обертка надо всем, то-ли криво спроектированный dependency injection container?

Аннотации - такой же facepalm, как и XML с неймспейсами. Куда мир катится...

радоваться надо - вокруг кризис, а тут столько новых рабочих мест сразу появилось! фабрики - рабочим, землю - крестянам, жабу - быдлу!

кривой дизайн самого API

А что там особо кривого (за исключением разве-что Hibearnate/JPA/JDBC Template)?

спеком Ж:)

Модульность это все решает. В отличии от JEE где контейнеры (GlassFish,JBoss,WebSphere,WebLogic поднимают кучу хлама.

А что там особо кривого (за исключением разве-что Hibearnate/JPA/JDBC Template)?

Кроме упомянутого вами - абсолютно даунская реализация dependency injection.

Но поставим вопрос иначе: а что там не кривое?

молодой человек может предложить достойную замену? только, пожалуйста, замену _всему фреймворку_, а не некоторым частям!
или достал апсиратель и апсираешь? может, тогда в троллксы?

Кроме упомянутого вами - абсолютно даунская реализация dependency injection.

А чем di конкретно не нравится? Имхо все более-менее адекватно сделано.

Но поставим вопрос иначе: а что там не кривое?

Собственно di вполне адекватный. MVC тоже нормальный, jmx и jms интеграция тоже вменяемая.

По крайней мере в третьем. Более ранними я давно не пользовался, не помню уже.

Поддержка Servlet 3.0 позволяющая полностью отказаться от XML файлов конфигурации;

Отлично.

Ява не для детей.

Кроме упомянутого вами - абсолютно даунская реализация dependency injection.

А чем di конкретно не нравится? Имхо все более-менее адекватно сделано.

Адекватно чему?

Это нормально, что описания beans и их связи являются не декларативными а императивными? То, что из-за этого просто порядок их упоминания в файле имеет огромное значение. Что поменяв порядок Spring начинает блевать эксепшнами на траниц пять с маловменяемым содержанием?

Причем сделать нормально, декларативно, может и толковый школьник. А еще он может элементарно написать код, что вместо тонны бредовых эксепшнов просто распечатает неразруливаемую циклическую зависимость.

А нормально, что вместо того, чтобы просто это пофиксить, предлагается не использовать конструкторы с аргументами, и вместо этого все данные передавать сеттерами а потом по необходимости дергать init? Это в их понимании «best coding practice». Пипелац полный. Это просто получается какая-то ява для анацефалов.

P.S. Я надеюсь, что и так очевидно, почему декларативное описание связей лучше императивного и почему конструкторы с аргументами лучше конструктора без оных и с кучей сеттеров впридачу?

Смутно помню, что были еще какие-то извраты и недочеты. Но сходу детали не помню. Вроде бы

а) Spring скидывает все имена бинов в одно пространство имен, что создает адский страч. Причем плохо разргебаемый, когда у тебя кучка связанных XMLей с описанием бинов и кто-то сделал крооохотное изменение в своей XMLке, что неожиданно вылезло в конфликт с твоим «творчеством»

б) были какие-то кривости в плане того, как можно параментризовать описание. Да, можно подгрузить properties и передать их значения (по крайней мере кое-какие из них) через сеттеры в бины. Но по-моему связывание бинов параметризовать не было возможным.

jmx и jms интеграция тоже вменяемая.

jms имел несчастье видеть. Пришлось ее убрать к чертям. Код может и ничего, вот только не дружил в таким Ъ enterprise как Weblogic JMS. Spring там как-то интересно жонглировал всякими там data sources и часть объектов плодил из одного, часть из другого и потом объединенная химера не хотела жить.

Еще видел Springовую обертку над JDBC. Уж лучше без нее чем с ней. Кода получается _намного_ больше и он - запутанней. Зато любители Spring и антипаттернов фапают по-полной.

молодой человек может предложить достойную замену? только, пожалуйста, замену _всему фреймворку_, а не некоторым частям!

или достал апсиратель и апсираешь? может, тогда в троллксы?

Подозреваю, что по сравнению с вами я уже немолодой. :)

АМне мегафреймфорк никогда не был нужен. Зачем он? Инструмен выбирается под задачу, а не чтобы вписать его в CV в стиле «Я макака, что обучена грызть Spring».

По-сути, единственное, что мне было когда-либо нужно из всего того, что делает Spring - dependency injection. Все остальное либо вообще не нужно, либо делается прекрасно непосредственно стандартным библиотеками Java.

jms имел несчастье видеть. Пришлось ее убрать к чертям. Код может и ничего, вот только не дружил в таким Ъ enterprise как Weblogic JMS. Spring там как-то интересно жонглировал всякими там data sources и часть объектов плодил из одного, часть из другого и потом объединенная химера не хотела жить.

Опечатка: не data source а connection pool. Слава богу, уже года два как начал забывать терминологию JMS.

Такое ощущение, что вы видели спринг лет 5 назад. Аннотациями всё помечается декларативно, зачем какой то XML, я не знаю. Циклические зависимости у меня лично никогда не возникали. Вообще я плохо представляю, как разрулить циклическую зависимость конструкторами, видимо никак, так что спринг правильно говорит, сеттеры ваше всё, а ещё лучше не делать циклических зависимостей, есть что то неправильное в этой идее.

А сеттеры лучше конструкторов потому, что с ними всё понятно без чтения жавадока.

new Blablabla(1, 2, 3, "bbb", 0.7);

vs

bla = new Blablabla();
bla.setWeight(1).setWidth(2).setHeight(3).setTitle("bbb").setOpacity(0.7);

а) Spring скидывает все имена бинов в одно пространство имен, что создает адский страч. Причем плохо разргебаемый, когда у тебя кучка связанных XMLей с описанием бинов и кто-то сделал крооохотное изменение в своей XMLке, что неожиданно вылезло в конфликт с твоим «творчеством»

Есть контексты, аналог namespace-ов, вроде. Правда надобности использовать не было.

Еще видел Springовую обертку над JDBC. Уж лучше без нее чем с ней. Кода получается _намного_ больше и он - запутанней. Зато любители Spring и антипаттернов фапают по-полной.

Тут убогость Java, лучше никак. Можно и без неё, если не нравится, никто же не заставляет. Вообще try-with-resources сильно облегчает работу с JDBC, ещё бы убрали Checked Exceptions из языка и именованные параметры в PreparedStatement-ы добавили, можно было бы JDBC использовать без матов.

Такое ощущение, что вы видели спринг лет 5 назад.

Не, 3 года назад. %)

Аннотациями всё помечается декларативно, зачем какой то XML, я не знаю. Циклические зависимости у меня лично никогда не возникали. Вообще я плохо представляю, как разрулить циклическую зависимость конструкторами, видимо никак, так что спринг правильно говорит, сеттеры ваше всё, а ещё лучше не делать циклических зависимостей, есть что то неправильное в этой идее.

ОК. Вот допустим надо сделать так:

Есть class A {

A(B b);

}

и class B {

setA(A a);

}

Нужно, чтобы создались A и B. Причем экземпляр B передается в конструктор A, а A передается в B сеттером. Да, и конечно, на самом деле есть еще несколько сеттеров, и данные хотелось бы из .properties вытащить, но для простоты про это можно забыть.

Как это можно сделать аннотациями?

И почему Spring собирает эти бины в кучу только если у него хорошее настроение, хотя выяснить, что сначала надо создать экзепляр B, потом А, и лишь затем дернуть сеттер в B - совсем тривиально?

А сеттеры лучше конструкторов потому, что с ними всё понятно без чтения жавадока.

1. Если код Ваш - Вы и так в курсе что к чему. А если не Ваш, то javadoc читать скорей всего прийдется, чтобы понять контракт класса.

2. Тут, конечно, недостаток Java - нет именованных параметров. Ну и ладно.

3. Контрпример:

class Pair {

private int x, y;

void setX(int x) { this.x = x;

}

int getX() {

return x;

}

void setY(int y) { this.y = y;

}

int getY() {

return y;

}

}

лучше чем

class Pair {

public final int x, y;

Pair(int x, int y) {

this.x = x;

this.y = y;

}

}

?

ещё бы убрали Checked Exceptions из языка

Не дай Бог. CheckedExceptions гарантируют, что будет выброшено только то, что ожидается. Писать, когда не очевидно, что и при каких условиях будет «выкинуто» - жесть. Особенно, когда это вылезает при каких-то экзотических условиях, не отлавливаемых нормальным тестированием, и тебя из-за этого могут разбудить ночью. Нафиг-нафиг. Но тут, конечно, еще и вопрос вкуса.

и именованные параметры в PreparedStatement-ы добавили

Именованные параметры - благо. Согласен.

bla.setWeight(1).setWidth(2).setHeight(3).setTitle(«bbb»).setOpacity(0.7);

Какое уродство.

Не дай Бог. CheckedExceptions гарантируют, что будет выброшено только то, что ожидается.

Не гарантируют. Легко кидать checked exceptions из метода, который их не объявил.

Изредка checked exceptions могут быть полезны, чего-нибудь вроде UserNotFoundException. Но SQLException должен быть unchecked, и вообще все исключения в JDK, потому что в 140% случаях текущая ситуация ведёт либо к throws SQLException везде в DAO слое, либо к try { ... } catch (SQLException e) { throw new RuntimeException(e); }.

Писать, когда не очевидно, что и при каких условиях будет «выкинуто» - жесть. Особенно, когда это вылезает при каких-то экзотических условиях, не отлавливаемых нормальным тестированием, и тебя из-за этого могут разбудить ночью. Нафиг-нафиг. Но тут, конечно, еще и вопрос вкуса.

Мне хватает unchecked exceptions, их никто не запрещает перечислять в throws для документирования.

А как красивее в Java?

Как это можно сделать аннотациями?

И почему Spring собирает эти бины в кучу только если у него хорошее настроение, хотя выяснить, что сначала надо создать экзепляр B, потом А, и лишь затем дернуть сеттер в B - совсем тривиально?

Проверил - поведение такое же, зависит от порядка классов, в котором он их просматривает. Хз, глупое поведение, конечно, наверное можно попробовать зарепортить как баг.

Подозреваю, что по сравнению с вами я уже немолодой. :)

да, ваше заседенелое муде внушает :-D всё, умолкаю.

Хотя бы уж не выпендриваться и написать несколько операторов.

Не дай Бог. CheckedExceptions гарантируют, что будет выброшено только то, что ожидается.

Не гарантируют. Легко кидать checked exceptions из метода, который их не объявил.

Может мы о разном? Можно пример, как можо именно checked exception кинуть, не объявляя его в «throws»?

Проверил - поведение такое же, зависит от порядка классов, в котором он их просматривает. Хз, глупое поведение, конечно, наверное можно попробовать зарепортить как баг.

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

Похоже на стандартный ответ «толкового» саппорта:

юзер: «какого ваш сайт не работает? и вообще порт 80 у вас закрыт»

саппорт: «какой у вас браузер?»

юзер: «Firefox. Но браузер не при чем. У вас сервер упал.»

саппорт: «Мы не поддерживаем ничего, кроме IE»

юзер: «Под IE тоже не работает»

саппорт: «Мы поддерживаем только IE 5»

юзер: «Чеооо?! Его же уже давно черви съели на кладбище»

саппорт: «Ничего не знаю, поддерживается только IE 5»

юзер: «Пилять... Вообще-то на IE 5 тоже не работает. И не может работать. И, еклмн, чего вы мне тюльку травите?»

саппорт: «Это Вы меня пытаетесь сбить с толку. Ничего не знаю про эти ваши порты, у нас такого в документации нет»