Spring Framework 2.5

> стандартные решения должны описываться с помощью того же самого языке программирования и помещаться в стандартную библиотеку

Возможно, я знаю мало языков, но мне неизвестны языки, где можно запрограммировать высокоуровневый ПОДХОД к решению проблем.

>>> Напрашивается очевидный вывод: важно, не на чём писать, а как.

>> не как а что

> Не что, а зачем :D

Не зачем, а почём! (подход настоящего ынтерпрайзового жабщика)

Java Config посмотрите - интересная штука.

http://www.springframework.org/javaconfig

>> Эти-то термины придуманы уж лет 50 как,

> И что? От этого что-то меняется?

Нет,

> Вообще смешно прозвучало: "что вы все абру какуюто птичью придумали када все нормальные люди кадаброй пользуются"

Не так. "Что вы все абру какуюто птичью придумали када кадабра для всего этого давно уже придумана" - вот так.

> "А вот у нас в питоне" звучит как "а вот в нашем дворе"

Покажи мне хоть одно слово "Питон" в моих постингах.

>Думаю, придется самому написать, ведь питон же настолько более высокоуровневый и обобщенный язык чем Java, что питонщик средней руки пишет в день код по функциональности превышающий в 10 раз код, написанный за день средним жабистом. Так что за ~недельку ты один аналог Spring я думаю напишешь

зачем писать? http://en.wikipedia.org/wiki/Spring_Python

> Как оно по производительности по отношению к Django?

Who's using Spring?

There are thousands of production applications using Spring. Users include investment and retail banking organizations, well-known dotcoms, global consultancies, academic institutions, government departments, defense contractors, several airlines, and scientific research organizations (including CERN). Some examples:

- Voca, Europe's largest processor of direct debit & credit transactions, uses Spring heavily in a system that processes billions of payments per year. The introduction to Spring helped drive a significant gain in developer productivity, and Spring plays an important role in processing each of over 80 million payment instructions daily. Interface21's expertise was instrumental in the architecture of Voca’s core payment engine. - eSpaceNet, the European patent office's online patent database, is responsible for managing all patents across the continent of Europe. Spring's web application development solutions have improved productivity, enhanced performance, and reduced maintenance costs. - Sabre Airlines Solutions, the leading provider of airline information systems, uses Spring throughout their next-generation aircraft control system. Accenture, one of the world’s leading SIs, uses Spring extensively in client engagements and best practice solutions. Accenture has also contributed to the Spring Portfolio through collaborating with Interface21 to create the Spring Batch project. - Nine out of the top 10 global banks use Spring extensively in Java applications. Several have standardized on Spring to structure their applications.

Как вы думаете, такие вещи бы стали писать на Spring, если бы он проигрывал в производительности джангам и прочим?

так уже было сказано что Spring не веб фреймворк в отличии от django, зачем сравнивать теплое с мягким?

> зачем писать? http://en.wikipedia.org/wiki/Spring_Python

А ещё есть http://www.springframework.net :)

>А ещё есть http://www.springframework.net :)

да, именно его в данный момент обсуждаем :)

>Круто. Уже скачал. Изменения отличные.

Слушай, а где у него "Introduction tutorial", "Quick Start"?

> - Nine out of the top 10 global banks use Spring extensively in Java applications. Several have standardized on Spring to structure their applications.

>Как вы думаете, такие вещи бы стали писать на Spring, если бы он проигрывал в производительности джангам и прочим?

Аналитики сЛОРа не одобряют использование Spring 9-ю ведущими банковскими системами из 10. Банковским системам пох, они гребут бабло, пока аналитики сЛОРа с красными глазами учат Лисп

> да, именно его в данный момент обсуждаем :)

Дык то *.net, а то *.org ;-)

Самое интересное, что говорят тут о Спринге негативно люди, которые его и в глаза ни разу не видели. Просто у них аксиома: "Питон - рулез, Жаба - суксь !". Видел я тут одного знакомого, который ни Питоне лабал веб-проект. Так он заколебался к Питоновским фреймворкам костыли привинчивать.

Любезнейший, это ложь.

> Как вы думаете, такие вещи бы стали писать на Spring, если бы он проигрывал в производительности джангам и прочим?

Стали бы.

(Если вопрос был риторическим и ожидаемый ответ "нет", то вы излишне высокого мнения о людях вообще и разработчиках в частности.)

Насколько я понял идую DI, то вот, довольно элегантная реализация от Trac (код): http://trac.edgewall.org/browser/trunk/trac/core.py

Документация: http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

Кстати, да.. Вещица неплохая.. ;-)

Хм.. Одни Java Web Developers собрались на LOR-e.

> А вот почему у жабщиков на каждый чих столько buzzword-ов?

Потому что то, что в питоне делается одной строчкой с использование базы языка, в Яве требует очередного JEE framework. :-/

PS Не хочу никого обидеть, но Ява - быдлоязык.

Кстати, а зачем оно нужно в свете JEE 5? Чем канонические JFS + EJB3 + Persistence не годятся?

> Давно хочу _нормальный_ IoC-контейнер для Питона со сравнимыми фичами, чтобы можно было экстернализировать конфигурацию. > Где можно его взять, а потом легко пользоваться?

Сюда не смотрел? http://sourceforge.net/projects/pycontainer/

Правда он никому не нужен :)

>так уже было сказано что Spring не веб фреймворк в отличии от django, зачем сравнивать теплое с мягким?

так люди не понимают как может быть фреймворк да не под веб :)
я на 100% уверен что тут большинство о Spring и не слышало. т.к. литература по нём нормальая только англоязычная а книжки стоят сколько тут анонимусы в месяц не зарабатывают.

> я на 100% уверен что тут большинство о Spring и не слышало. т.к. литература по нём нормальая только англоязычная а книжки стоят сколько тут анонимусы в месяц не зарабатывают.

Я конечно рад, что ты ты покупаешь книжки на английском по 2килорубля за штуку, потому что я все не могу начать жить честно в этой области - осел скачивает книжки за время чтения мнений читателей я о них, после чего книжка с большой вероятностью отправляется в помойку :(

Из позитивных книг по яве (т.е. не Тейт) желание прочитать пока вызвал только бесплатный JEETutorial :)

> Аналитики сЛОРа не одобряют использование Spring 9-ю ведущими банковскими системами из 10. Банковским системам пох, они гребут бабло, пока аналитики сЛОРа с красными глазами учат Лисп

Газели перевозят миллионы человек в день в одной Москве и являются наиболее используемыми в нашем мухосранске микроавтобусами, с помощью которых автоперевозчики гребут бабло. Отменяет ли это тот факт, что Газель - дерьмо?

>Как оно по производительности по отношению к Django?

Что именно 'как'? В Spring'е вообще-то много вещей.

Если сравнивать голый web-фреймворк, то Spring будет раз в 20 быстрее за счет компилируемости Java.

Вот тут: http://rsdn.ru/Forum/message/2739549.flat.aspx#2739549 ,- я сравнивал простое JEE-приложение и PHP-скрипт. PHP в одном тесте слил в 20 раз, в другом тесте (где bottleneck'ом стала база) - в два раза. Думаю, что Django будет работать примерно на уровне скорости PHP.

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

Вот возьмем всеми любимый тут Лисп. Можно, например, выделить в Лиспе паттерн "ленивый список". Значит ли это, что Лисп отправляется в топку?

>Да нет, я против самой категории. Просто отсутствие вкуса порождает рак buzzword'ов. >И buzzword уже не проясняет ситуацию, а запутывает.

Spring в отношении buzzword'ов - это феномен, так как именно Spring единолично _запустил_ buzzword IoC года так три-четыре назад.

> Аналитики сЛОРа не одобряют использование Spring 9-ю ведущими банковскими системами из 10. Банковским системам пох, они гребут бабло, пока аналитики сЛОРа с красными глазами учат Лисп

Надо запомнить что банк начинается не с кредитной политики и управления финансами. Потому что только с помощью Spring банки могут грести бабло. Если уж приводить примеры, то из области IP, а не из овощеводства, например, где использовать будут то, что им посоветовал "крутой" специалист.

> Кстати, а зачем оно нужно в свете JEE 5? Чем канонические JFS + EJB3 + Persistence не годятся?

Ну, во-первых всё-таки JSF. Во-вторых, если кратко, ejb - дерьмо, расписывать подробнее здесь особой радости нету, кому интересно, прочитают J2EE Development without EJB Рода Джонсона (основоположника Spring).

> Ну, во-первых всё-таки JSF. Во-вторых, если кратко, ejb - дерьмо, расписывать подробнее здесь особой радости нету, кому интересно, прочитают J2EE Development without EJB Рода Джонсона (основоположника Spring).

Это он про EJB 2.0 писал, я полагаю. Но EJB 3.0 выглядят сильно веселее.

> Во-вторых, если кратко, ejb - дерьмо.

Просто я в настоящий момент как раз занимаюсь самоликбезом по JEE 5, и надо сказать по сравнению с J2EE 4, доку по которой я забросил с криком ужаса на дескрипторах в XML-файлах, тут можно просто плакать от счастья... если бы не убожество жабы как языка, конечно :)

> Это он про EJB 2.0 писал, я полагаю. Но EJB 3.0 выглядят сильно веселее.

Чем веселее? Стало меньше файлов и появилась возможность использовать аннотации? Это мелочи.

>Чем веселее? Стало меньше файлов и появилась возможность использовать аннотации? Это мелочи.

Ну как сказать. EJB3 = Hibernate + Spring :)

Конечно, IoC они сильно упростили и в JPA не хватает многих фич Hibernate. Но уже вполне можно жить.

> Слушай, а где у него "Introduction tutorial", "Quick Start"?

По ссылкам сходи, там все есть. И отдельно изменения от 2.0 до 2.5 и обновленный reference до 2.5. =)

> Кстати, а зачем оно нужно в свете JEE 5? Чем канонические JFS + EJB3 + Persistence не годятся?

Spring может прекрасно работать с JSF & EJB/JPA. Spring это в первую очередь IoC - связующее звено.

+10

Перешел с EJB на Spring. Очень доволен.

Концепция IoC c ORMами - большой позитив.

Все зависит от конкретной задачи.

JSF имеет один существенный недостаток - надо брать "большой напильник", чтобы GET'ы вместо POST'ов поддерживать. Проблема решаема, но не совсем красиво.

>Вот тут: http://rsdn.ru/Forum/message/2739549.flat.aspx#2739549 ,- я сравнивал простое JEE-приложение и PHP-скрипт. PHP в одном тесте слил в 20 раз, в другом тесте (где bottleneck'ом стала база) - в два раза. Думаю, что Django будет работать примерно на уровне скорости PHP.

Причем тут php? Django использует python.

Объективно Django -- самый быстрый скриптовый веб-фреймворк, многочисленные тесты это доказали.

Мой вопрос касался простого сравнения Spring и Django есть ли результаты тестов на реальных веб-приложениях.

> пока аналитики сЛОРа с красными глазами учат Лисп

Любителей-теоретиков на ЛОРе стало не так уж много - просто они создают информационный шум, когда речь заходит о Java, Mac OS X, Red Hat и прочих вещах.

Мы обсуждаем (позитивные!) новости, а не поддаемся на троллинг.

Да и еще сходил по вашей ссылке, мягко говоря не однозначное сравнение, тестирование шло :

"Для тестирования я использовал apache2, php5 и mod-php из стандартной поставки Debian (unstable), никакого дополнительного тюнинга не делал."

Про использование апача на frontend с модулями mod_php/mod_perl и т.д. уже сказно много, но сравнивать производительность нужно все же по верхней планки. Что говорить, а если бы это был не апач, а ngix или лайти c FastCGI кто-бы сосал?

> Ну как сказать. EJB3 = Hibernate + Spring :) Конечно, IoC они сильно упростили и в JPA не хватает многих фич Hibernate. Но уже вполне можно жить.

Всё равно необходимость в толстом и практически бесполезном ejb-контейнере остаётся.

>Причем тут php? Django использует python.

Они оба интерпретируемые, примерно одинаковые по скорости.

>Объективно Django -- самый быстрый скриптовый веб-фреймворк, многочисленные тесты это доказали.

Скриптовой - возможно. Вот только Java может соперничать с FastCGI на С/C++.

>"Для тестирования я использовал apache2, php5 и mod-php из стандартной поставки Debian (unstable), никакого дополнительного тюнинга не делал."

Справедливости ради, никакого тюнинга Jetty и JVM я тоже не делал.

>Про использование апача на frontend с модулями mod_php/mod_perl и т.д. уже сказно много, но сравнивать производительность нужно все же по верхней планки. Что говорить, а если бы это был не апач, а ngix или лайти c FastCGI кто-бы сосал?

Для эксперимента зарулил запросы к Jetty через mod_proxy в Apache2. Результат Java упал на 15%.

То есть, мы можем считать эти 15% из _двадцатикратного_ преимущества результатом overhead'а от Апача.

Т.е. идеальный веб-сервер, имеющий абсолютно нулевой оверхед, ускорил бы PHP-версию примерно на 15%. Ну еще процентов 50% можно какими-нибудь тюнингами добрать.

Но Java-то в этом случае все равно будет примерно в 10 раз быстрее!

>Они оба интерпретируемые, примерно одинаковые по скорости.

абсолютно неверное замечание, и по скорости и по возможностям, по парадигме, это абсолютно два разных языка. Кстати python также использует байт-код, так что к чистым интерпретаторам его отнести сложно.

>Скриптовой - возможно. Вот только Java может соперничать с FastCGI на С/C++.

Без реальных результатов тестов это просто болтовня.

>Справедливости ради, никакого тюнинга Jetty и JVM я тоже не делал.

Дело собственно не в тюнинге, а в правильном приготовлении выскопроизводительного веб-приложения. Апач на каждое соединение с вызовом mod_* (mod_proxy не из этой оперы) тратит от 1 до 100 Мб (и более) физической памяти, причем они висят даже если клиент не активен. О высокой производительности с таким расходом ОЗУ речи вообще нет. При превышении кол-ва соединений критического уровня (который довольно низок) получаем сплошной своп.

>Но Java-то в этом случае все равно будет примерно в 10 раз быстрее!

php, но не django с python'ом.

> JSF имеет один существенный недостаток - надо брать "большой напильник", чтобы GET'ы вместо POST'ов поддерживать. Проблема решаема, но не совсем красиво.

Ну как выяснили выше, Java, она для платежных систем, а не былдомагазинов, считающих ссылки с market.yandex.ru :))

А чем чудовещен подход с http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls и outputlink? Или я что-то пропустил? (я еще в ликбезе до этого не дошел, так что теоритизирую).

> Но Java-то в этом случае все равно будет примерно в 10 раз быстрее!

Для сравнения с питоном надо сравнивать с питоном. Глядя на задумчивость при перезагрузке прилождения JEE, начинаешь подозревать, что JIT яву может и не спасти...

>Дело собственно не в тюнинге, а в правильном приготовлении выскопроизводительного веб-приложения. Апач на каждое соединение с вызовом mod_* (mod_proxy не из этой оперы) тратит от 1 до 100 Мб (и более) физической памяти, причем они висят даже если клиент не активен.

Это не так. При проведении теста потребление памяти не поднималось значительно.

>О высокой производительности с таким расходом ОЗУ речи вообще нет. При превышении кол-ва соединений критического уровня (который довольно низок) получаем сплошной своп.

Тоже не так. Никакой активности диска во время первого теста не было. Я бы такую "мелочь" уж заметил бы.

>Для сравнения с питоном надо сравнивать с питоном. Глядя на задумчивость при перезагрузке прилождения JEE, начинаешь подозревать, что JIT яву может и не спасти...

Это смотря как их готовить. В первой итерации приложения мы использовали JEE (в виде JBoss'а) - время запуска было порядка 30 секунд. Меня это быстро достало, и я за пару дней выкинул из JBoss'а кучу ненужных мне сервисов и довел время запуска до 7 секунд.

Во второй итерации мы перешли на Jetty + Spring, и время запуска стало 3.5 секунды (включая запуск JVM).

>абсолютно неверное замечание, и по скорости и по возможностям, по парадигме, это абсолютно два разных языка. Кстати python также использует байт-код, так что к чистым интерпретаторам его отнести сложно.

Мне на парадигмы вообще плевать. Питон - это чистый (если не считать Psyco, помогающий далеко не всегда) динамический интерпретируемый язык, его байт-коды - это просто заранее разобраный текст программы. Интерпретатор нельзя заставить работать быстро, как ни пинай его.

Java - это JIT-компилируемый язык со статической типизацией.

(В теории, есть надежда на то, что PyPy сделают нормальный спекулятивный JIT-компилятор, наподобии HotSpot VM, но пока это еще не случилось)

>Без реальных результатов тестов это просто болтовня.

Предлагайте тесты...

> Во второй итерации мы перешли на Jetty + Spring, и время запуска стало 3.5 секунды (включая запуск JVM).

Да, полагаю при таком раскладе Ява должна выиграть. (но что же это за ява без JEE AS? Тут же можно было и django обойтись :)