Java web

Кто в теме, просветите, пожалуйста, JavaEE за эти годы стала хоть немного приятнее и приветливее к девелоперу?

Куда уж дальше?

Или до сих пор приходится писать тонны хмл и кода для хеллоу ворлда?

Никогда не приходилось.

Есть мавеновские архетипы,например.

Появился Spring 4 со spring boot, в котором для хеллоу ворлда вообще ни строчки xml писать не обязательно. А конфигурировать при помощи аннотаций можно давно. Но тут уже дело вкуса. Некоторые джависты почему-то любят иметь кучи xml вместо java-кода. Надеюсь, что просто по привычке. А вообще мне самому интересно почему.

Чтоб не перекомпилировать тогда, когда можно не перекомпилировать?

Ключевое слово легаси. Я по долгу службы пока вот не могу перелезть на спринг 4.

На Java EE 7 смотрели?

Лолшто? Эти так называемые «настройки» и так ни разу не предназначены для того, чтобы их менял кто-то кроме разработчика. Пользовательские настройки выносятся отдельно. А если конфигурацию меняет разработчик, то перекомпиляция - это самая элементарная операция из того, что можно придумать. При этом она (пересборка) и так неизбежна.

Ну третий спринг вот тоже прекрасно конфигурируется кодом с аннотациями, но я что-то пока не видел чтобы этот способ был популярен.

По моему, там всё только переусложнили. Слишком многословный код.

Никогда не приходилось.

Приходилось :)
Сложно? http://spring.io/guides/gs/actuator-service/

Чтоб не перекомпилировать тогда, когда можно не перекомпилировать?

Для этого есть груви конфиг. Да и вообще изменять конфиг на рабочем продакшене (иначе зачем избегать компиляции?) дело неблагодарное.

Если брать именно java ee, то с седьмой версии много чего (но не все) можно писать без xml вообще.

А если брать просто java, то веб или вообще что угодно без xml уже давным давно есть.

а ещё меня всегда убивало в .NET, что в нем умудрились лямбдами все настолько усложнить, что приходится полчаса вчитываться в код, чтобы понять, что в нем происходит.

а что не нравится в XML?

берем тучу готовых проектов и либ, и склеиваем их между собой, пишем клей, получается собственное приложение. вот эти «готовые проекты» перекомпилировать часто вообще невозможно (нет исходников), а если и можно - то это долго и вредно. а склеивать-то всё равно надо. и тут нам приходит на помощь тот самый XML!

вообще, помойму самое крутое в джаве - как раз отсутствие необходимости в перекомпиляции. У нас был проект, в котором половина исходников потеряна, и джарки собраны сто лет назад. И ничо, всё работает ОК.

Не нравится xml не используй, а если залез в xml'оемкие тулзы при чём тут язык?

Это уже никакая не джава, а программирование на XML - тут я согласен с оценкой ТСа. Библиотеки можно склеивать без всяких XML.

перекомпилировать часто вообще невозможно (нет исходников), а если и можно - то это долго и вредно

А это вообще тройной фейспалм. Чтобы собрать проект с какой-то библиотекой, её исходники вовсе не обязательны. А уж нытьё про время сборки - это просто курам на смех.

А причем тут язык? Речь о JEE, если ты не заметил.

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

А уж нытьё про время сборки - это просто курам на смех

при чем тут время сборки. Ты можешь тупо не смочь собрать какой-то проект, потому что там творится полный страх у ужас в исходниках. Например, каждый разработчик проекта знает что мастер использовать нельзя, можно использовать бранч temp-vasya-fixes наложенным патчем из папки /other, и конфиг заменить на тот что всем рассылали по почте в девелоперской рассылке, и потом вручную еще поправить абсолютные пути чтобы совпадали с компьютером на котором собирается. Хорошо хоть не соберется с ошибкой, может быть хуже - соберется, но неправильно. Постоянно такое происходит. Хорошо когда новый проект, а может быть наоборот - ему десять лет, говнище полное, все разработчики уже разбежались, спросить совета не у кого. Хорошо когда есть уже собранная джарка - вот она собрана, и теперь руками ее не трогать.

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

Если библиотеку не сможет прикрутить мавен по причине конфликта каких-то зависимостей, то сервер приложений её тем более не сможет прикрутить - они ещё менее гибкие в этом плане.

при чем тут время сборки. Ты можешь тупо не смочь собрать какой-то проект, потому что там творится полный страх у ужас в исходниках. Например, каждый разработчик проекта знает что мастер использовать нельзя, можно использовать бранч temp-vasya-fixes наложенным патчем из папки /other, и конфиг заменить на тот что всем рассылали по почте в девелоперской рассылке, и потом вручную еще поправить абсолютные пути чтобы совпадали с компьютером на котором собирается. Хорошо хоть не соберется с ошибкой, может быть хуже - соберется, но неправильно. Постоянно такое происходит.

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

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

Ну и не трогай её руками. Почему при этом её нужно прикручивать обязательно именно XML'ем?

этап компиляции позволяет выявить много ошибок (причем тех кто не выявляются юнит тестами)

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

Ну это не совсем то, конечно.

Спринг бут это такая вещь, с которой нет проблем либо на маленьком проекте, либо когда не нужно писать свою конфигурацию, а дальше начинаешь дрочить вприсядку.

Да у джавы легаси везде. До сих пор натыкаюсь на вакансии где требуют знание джавы 1.4 и 1.5. Бедные люди.

Кстати, а в чём принципиальное отличие 3 спринга от 4?

В асп.нете?

Мельком. Вот и хотелось бы узнать у тех, кто плотно работал что там хорошего добавили в сравнении с 5 и 6 версией. Ускорилась ли разработка, если интересные фичи. Можно ли написать интернет магазин за 20 минут :D

Что ты под своей конфигурацией имеешь в виду?

О, неплохо. Посмотрел другие примеры, виден прогресс. А в jee есть что-то похожее?

В минимально необходимой версии джавы.

Да понятно, что можно обойтись без тонн xml. Про пересборку - это только предположение, мало ли, может кто-то для разных сред использует разные дескрипторы, например. Все равно это не тонны xml получаются. Я вот тоже предпочитаю аннотации, но у нас есть куча чужого кода с тоннами xml - и переписывать его нецелесообразно.

ИМХО, лямбды читать намного приятнее, чем тонны хмл. В джаве такое бы не помешало. Иногда приходится сталкиваться с джавой и после дотнета это дикая боль.

Ну мне не нравится читать его, когда его много. Уж лучше json.

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

Чем еще ее прикручивать без перекомпиляции?

Я не видел.

Той же джавой. Для этого совершенно не нужно что-либо делать с самой библиотекой.

библиотека A зависит от библиотеки B. Пользователю это не нравится, и хочется чтобы вместо B была C, совместимая с ней по интерфейсам. Под «зависимостью» понимаются не пакеты в терминах Maven, а например переход на новый веб-сервер с другой реализацией контейнера сервлетов или чего-то такого.

Разработчики A предполагали такой сценарий. Как разработчикам A правильно организовать программу, чтобы это стало возможным?

разработчикам А обращаться везде к интерфейсам без упоминания реализации, юзать EE-шные бины. Пользователям А положить в classpath библиотеку C вместо B. Сами бины пущай контейнер разруливает.

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

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

Жаба не лучше.

Вот у меня сейчас открыт jee проект в котором 3 xml'ки, все сгенерились и обновляются из ИДЕ. Ну и ещё антовские скрипты, которые тоже сгенерились из ИДЕ.

Возможно у тебя есть сервер и компилятор, которые не требует конфигурации приложений, поделишься ссылкой? Если нет, поясни чем json конфиг выигрывает у xml конфига.

Проще всего открыть код библиотеки ибо в том же томкате в каждой грёбанной мажорной версии какие-то уроды переделывают работу с интерсепторами, при чём так, что сходу сниппет для 5ого просто непонятно как переписать для 7ого. Тут не то что без перекомпиляции, тут с перекомпиляцией не заведёшь.

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

Тем, что json в разы читабельнее.

Стало вот интересно, а как с этим в джава?

так же

Идёт работа по упрощению написания вэбни?

зачем? кровавый энтерпрайз платит, сложность только растет, всем выгодно

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

Если изначально программная конфигурация хорошо продумана, то хорошо. Но такое нечасто встречается. И опять же исключает поддержку IDE.

Вопрос номер раз, каков же критерий «читабельности»? Вопрос номер два, как часто ты читаешь конфиги, не подправляешь пару строк а именно читаешь?