Вышел Spring Framework 3.1

ктоэта?! :-D

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

aol (14.12.2011 10:42:39)

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

roy (14.12.2011 11:19:20)

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

alx_me (14.12.2011 11:49:57)

Не нужно.

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

vada (14.12.2011 12:16:25)

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

CARS (14.12.2011 12:18:39)

Kolbasa

iBliss (14.12.2011 12:29:26)

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

Drolyk (14.12.2011 13:07:56)

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

dotbg (14.12.2011 13:21:56)

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

Absurd (14.12.2011 14:30:52)

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

r (14.12.2011 15:31:36)

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

vada (14.12.2011 15:58:29)

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

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

Yilativs (14.12.2011 16:38:34)

спеком Ж:)

vada (14.12.2011 17:48:02)

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

stevejobs (14.12.2011 18:14:00)

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

power (14.12.2011 18:17:01)

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

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

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

asaw (14.12.2011 22:11:21)

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

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

mikhalich (15.12.2011 1:53:00)

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

RedPossum (15.12.2011 2:42:34)

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

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

Nagwal (15.12.2011 4:17:04)

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

rtvd (15.12.2011 4:44:18)

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

rtvd (15.12.2011 4:46:45)

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

rtvd (15.12.2011 4:49:18)

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

JFreeM (15.12.2011 5:16:03)

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

JFreeM (15.12.2011 5:16:51)

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

vada (15.12.2011 11:28:52)

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

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

rtvd (15.12.2011 19:33:04)

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

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

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

Nagwal (15.12.2011 21:58:22)

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

Yilativs (15.12.2011 22:17:25)

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

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

rtvd (16.12.2011 8:04:18)

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

aol (16.12.2011 8:24:05)

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

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

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

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

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

Nagwal (16.12.2011 14:04:42)

Отлично.

mopsene (16.12.2011 14:06:04)

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

elnair (16.12.2011 14:58:17)

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

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

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

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

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

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

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

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

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

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

rtvd (17.12.2011 1:30:20)

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

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

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

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

rtvd (17.12.2011 1:34:55)

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

rtvd (17.12.2011 1:49:31)

Такое ощущение, что вы видели спринг лет 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);

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

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

Legioner (17.12.2011 1:52:07)

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

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

Есть 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;

}

}

?

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

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

rtvd (17.12.2011 5:23:29)

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

tailgunner (17.12.2011 7:38:55)

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

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

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

Legioner (17.12.2011 9:14:02)

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

Legioner (17.12.2011 9:14:53)

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

Legioner (17.12.2011 9:34:23)

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

aol (17.12.2011 10:12:17)

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

tailgunner (17.12.2011 10:42:04)

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

rtvd (17.12.2011 14:26:00)

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

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

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

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

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

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

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

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

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

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

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

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

rtvd (17.12.2011 14:33:15)