LINUX.ORG.RU

Java web

 ,


0

0

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

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



Последнее исправление: lazy_aleks (всего исправлений: 1)

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

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

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

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

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)

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

asaw ★★★★★
()
Ответ на: комментарий от bogus_result

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

asaw ★★★★★
()
Ответ на: комментарий от Hater

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

asaw ★★★★★
()
Ответ на: комментарий от bogus_result

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

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

f1xmAn ★★★★★
()

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

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

maloi ★★★★★
()

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

maloi ★★★★★
()
Ответ на: комментарий от asaw

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

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

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

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

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от asaw

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

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

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

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

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

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

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

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

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

asaw ★★★★★
()
Ответ на: комментарий от bogus_result

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

Deleted
()
Ответ на: комментарий от Deleted

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

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от asaw

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

lazy_aleks
() автор топика
Ответ на: комментарий от Hater

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

lazy_aleks
() автор топика
Ответ на: комментарий от bogus_result

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

lazy_aleks
() автор топика
Ответ на: комментарий от lazy_aleks

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

asaw ★★★★★
()
Ответ на: комментарий от asaw

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

bogus_result
()
Ответ на: комментарий от maloi

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

lazy_aleks
() автор топика
Ответ на: комментарий от stevejobs

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

lazy_aleks
() автор топика
Ответ на: комментарий от dizza

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

lazy_aleks
() автор топика
Ответ на: комментарий от asaw

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

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

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

arkhnchul ★★★
()
Ответ на: комментарий от stevejobs

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

asaw ★★★★★
()
Ответ на: комментарий от lazy_aleks

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

maloi ★★★★★
()
Ответ на: комментарий от f1xmAn

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

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

ya-betmen ★★★★★
()
Ответ на: комментарий от stevejobs

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

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

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

f1xmAn ★★★★★
()

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

так же

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

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

umren ★★★★★
()

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

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

Legioner ★★★★★
()
Ответ на: комментарий от lazy_aleks

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

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.