LINUX.ORG.RU

Java - на чём сейчас пишут?

 


3

5

Добрый день

Хотел поинтересоваться у местных аналитиков, на чём сейчас принято писать бизнес web-приложения в Java-Ынтерпрайз сообществе. Под Ынтерпрайзом в данном случае понимаются следующие ключевые слова:

  • Системы, которые пишутся 2+ года, поддерживаются и активно дорабатываются 15+ лет
  • Основная рабочая сила, которой предстоит это дело писать - среднестатический индус со среднестатической текучкой кадров
  • Куча интеграций с другими конторами, в основном на основе SOAP
  • Message queuing
  • Куча кода и бизнес правил в системе, специфических для конкретного клиента
  • Мобильные клиенты (Android, iOS) для работы с этой системой
  • Отчёты

Интересует всё - библиотеки, фреймворки, IDE, тулины, средства для тестирования, CI/VCS/IT, отчёты, итп.

Попросту говоря, что бы взял для разработки ЛОРовец, если бы ему пришлось сейчас с нуля организовать работу над чем-то подобным используя Java?

★★★★

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

Имей в виду, что это

Хотел поинтересоваться у местных аналитиков, на чём сейчас модно/стильно/молодёжно писать бизнес web-приложения в Java-Ынтерпрайз сообществе

и это

Попросту говоря, что бы взял для разработки ЛОРовец, если бы ему пришлось сейчас с нуля организовать работу над чем-то подобным используя Java?

разные вещи.

Куча интеграций с другими конторами, в основном на основе SOAP
Message queuing

Если выбор будет стоть между IBM и Oracle, могу порекомендовать смотреть в сторону Oracle SOA Suite, т.к. сделано человечнее чем IBMовское, особенно в плане отладки, а это 80% времени разработки интеграции.

Куча кода и бизнес правил в системе, специфических для конкретного клиента

Хз что тут подразумевается под правилами, но из опенсорца есть jBPM и Drools.

Мобильные клиенты (Android, iOS) для работы с этой системой

Главный совет: REST не подходит.

Отчёты

Как будто есть варианты

ya-betmen ★★★★★
()

фреймворки

Spring, Spring MVC, Hibernate. Мелких библиотек десятки, по ним конкретно спрашивай. Разве что для логгинга slf4j + logback и для юнит-тестирования junit можно считать современным стандартом.

IDE

Intellij Idea

тулины

что именно интересует? Для сборки maven.

средства для тестирования

Для юнит-тестирования хватает IDE. Для функционального тестирования уже надо детально смотреть требования.

CI/VCS/IT

Для хранения исходников SVN или GIT, разницы нет, что разработчики знают то и юзать. Обычно все SVN юзают. Для CI обычно Jenkins используют, хотя я всю жизнь скрипты на баше пишу на postcommit-хуки, мне это проще, чем в этих галочках тыкаться.

отчёты, итп.

Для отчётов MS Word обычно используют. Или речь про генерацию отчётов? Ну или HTML генерировать любым шаблонизатором от JSP до Freemarker-а какого-нибудь, или PDF генерировать (Apache FOP) или всякие ворды-эксели (Apache POI).

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

разные вещи.

Поправил описание, интересует второй вариант.

Хз что тут подразумевается под правилами, но из опенсорца есть jBPM и Drools.

Примерно это и подразумевается, но из опыта пока реально только написание кучи if/elso'ов, там где потенциально можно было бы посмотреть на BRMS.

Как будто есть варианты

То есть BIRT? А как-же Jasper, Pentaho?

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

Поправил описание, интересует второй вариант.

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

ИДЕ для интеграторов будет завязана на вендора, если ИБМ, то будет патченный дремучий эклипс, если Оракл, то что-то на основе нетбинса. Для остальных требовать определённую ИДЕ смысла нет. Ориентируйся на нетбинс.

Примерно это и подразумевается, но из опыта пока реально только написание кучи if/elso'ов, там где потенциально можно было бы посмотреть на BRMS.

Тогда тебе в Drools Expert. Прологовский стиль осваивается недели за 2-3. При желании можно даже ДСЛ наклепать.

То есть BIRT? А как-же Jasper, Pentaho?

Речь кажется шла про отчёты, на сколько знаю пентаха это аналитика, с биртом лично не сталкивался, но знакомые отчётники плевались.

ya-betmen ★★★★★
()

среднестатический индус

среднестатистические российские недобитки до сих пор не могут в отличать индусов от индийцев, что с них, среднестатистических, возьмешь.

Как говорил великий Джорджи Карлин:

«Задумайтесь о том, насколько туп среднестатистический человек, а затем прикиньте в уме, что половина из них еще тупее.»

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

Ты что-то не в ту степь залез. Почти все индусы в том самом понимании слова сейчас поголовно русские или выходцы из стран СНГ. Индийцы прокачавшие матан и программирование, а затем мигрировавшие в США, будут подороже русских и украинских Ванек на рынках труда; да и код у них за плечами качественнее.

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

Ага, вот почитал ваши ответы тут. Гоните на асп.нет, что, мол, библиотек мало. Так я посмотрю у вас там в джаве дела не лучше идут с годными библиотеками ;)

Также ~1-2. Так, собственно, зачем мучиться с джавой, если в асп.нете все сделано человечнее и менее костыльно?

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

GWT

Хорош Ыксперт. Может быть к 2015 году пора было выучить js + хотя бы одну библиотеку? Человеческий мозг умного человека может держать в памяти больше 1-2 языков, правда. Что за косность мышления?

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

Индус - это такая ос. Индус 1.0, 2.0, 3.0, 3.11, индус 95, индус 98, индус миллениум, индус энти, индус 2000, индус экспи, индус 7-8-10. Ну и индус фон.

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

Так я посмотрю у вас там в джаве дела не лучше идут с годными библиотеками ;)

При чём тут библиотеки?

Так, собственно, зачем мучиться с джавой

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

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

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

Так, ну-ка, что сделано кривее, чем в j2ee?

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

Так, ну-ка, что сделано кривее, чем в j2ee?

Ты первый.

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

Хорош Ыксперт. Может быть к 2015 году пора было выучить js + хотя бы одну библиотеку? Человеческий мозг умного человека может держать в памяти больше 1-2 языков, правда. Что за косность мышления?

Я то js знаю. Но ведь речь идет о проектах, жизненный цикл которых от 15 лет. Я в себе уверен, так же как и в своей команде, каждый из которой является ярким представителем элитарного специализма. Но вот в среднестатистическом индусе, который когда-то придет на проект, я не уверен. Javascript очень требовательный к скиллу язык. Еще пару строчек назад все смотрелось прекрасно, и тут бац - весь проект превратился в быдлокод. Вдобавок ко всему, тенденции касательно javascript очень часто меняются, и многие вещи, которые 10 лет назад считались классными, сейчас за них могут уволить. Поэтому в долгосрочных проектах джаваскрипта минимально, а gwt каждый индус знает.

slyjoeh ★★★
()

если хипстота то спринг - там есть все, если rock stable то javaee стек на базе какогонить жыбосса (это очень сумрачно) или гласс фиша

в качестве вебморды портал, интеграция через esb (но это настолько сумрачно что даже темно)

что бы взял для разработки ЛОРовец, если бы ему пришлось сейчас с нуля организовать работу над чем-то подобным используя Java?

взял бы голую яву, томкат и все. если совсем ленив то какойнить готовый ioc фреймворк (guice для ioc но толи я не докурил толи оно не позволяет добавлять биндинги через classpath)

Deleted
()

Системы, которые пишутся 2+ года, поддерживаются и активно дорабатываются 15+ лет

Ну ка хоть один пример такого проекта, пожалуйста. Твое поделие уже через 2 года будет ужасным легаси, а ты еще и на какие-то андроиды замахиваешься, о которых 3-4 года назад и не слышал никто. Пока у тебя переальфа выйдет мы смски сразу в мозг получать будем.

Попросту говоря, что бы взял для разработки ЛОРовец, если бы ему пришлось сейчас с нуля организовать работу над чем-то подобным используя Java?

Пистолет.

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

Ну ка хоть один пример такого проекта, пожалуйста. Твое поделие уже через 2 года будет ужасным легаси, а ты еще и на какие-то андроиды замахиваешься, о которых 3-4 года назад и не слышал никто. Пока у тебя переальфа выйдет мы смски сразу в мозг получать будем.

Я в последнее время соприкасался со старым поделием на дельфе. Огромная махина, две оракловые базы на сотни таблиц, миллионы строк кода. Свой компилятор, свой построитель GUI, много чего там намешано. Написано в 2000-м году. Так и пользуются. Хотели переписать, но уже 5 лет хотят, а денег на это не выделяют, а там нужно прилично денег, по моим оценкам не меньше миллиона баксов и нескольких лет, ибо система реально огромная. Но ты его никогда не увидишь, т.к. он стоит во внутренней сети госучреждения. Но с ним постоянно работают тысячи человек. И скорее всего так и будет работать ещё лет 100.

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

Bioreactor кастани, может быть он расскажет.
И обязательно напомнит о том, что нужно упорно готовиться к собеседованию.

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

У меня примерно такая же ситуация, с той разницой, что эти дремучие системы пока никто даже не собирается объявлять как legacy, а наоборот активно дорабатывают и продают.

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

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

Какая кому разница в тырпрайзе касательно тенденций джаваскрипта? Даже джава развивается, вон 8 версия вышла с налетом функциональщины, точно также за 10 лет поменялись подходы в разработке: ушел ант, пришел мавен с грэдлом и т.д., а тырпрайз до сих пор сидит на 1.4-1.5 и не волнуется. И с джс там будет тоже самое. Так что я не вижу здесь ни проблемы, ни противоречия.

А в долгосрочной перспективе - джс останется, а будущее гвт настолько туманно, что его нет. Оно, вроде, еще поддерживается кое-как, но у пациента, скорей, клиническая смерть.

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

GWT нормально поддерживается. Вон скоро 3-я версия выйдет, с кучей всяких киллер-фич. Новые версии выходят не очень часто, но фреймворк неспеша развивается и помирать не собирается.

Ты конечно прав, старые проекты, которые создавались в начале 2000-х, сидят на jdk 1.4, потому что переход на 1.5+ не представляется возможным. Но в контексте данной темы, ТС спрашивает про проекты, которые команда, в основном из индусов, сядет и начнет писать прямо сейчас. Насколько я понимаю, используя современные технологии. Так вот, я видел, что индусы делают с джаваскриптом, и я не думаю, что когда-нибудь снова захочу на это посмотреть. Пусть лучше они пишут на GWT, используя привычные инструменты.

slyjoeh ★★★
()

Java SE 8u45 JDK, NetBeans, Maven/Jenkins, Java EE 7, Cordova/PhoneGap.

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

А, тогда ладно, про 3 версию не видел. Зашёл к ним на гит там 2.7, вроде, последняя. Плохо смотрел.

А что, на гвт они лучше пишут? Он же, по идее, генерит тоже не особо читабельное. Что делать, если править придется?

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

Править же будешь исходник на джаве, а не заобфускейченный джаваскрипт.

slyjoeh ★★★
()

Системы, которые пишутся 2+ года, поддерживаются и активно дорабатываются 15+ лет

Последний стабильный Spring MVC

Основная рабочая сила, которой предстоит это дело писать - среднестатический индус со среднестатической текучкой кадров

Spring MVC задаёт структуру, которую все макаки понимают.

Куча интеграций с другими конторами, в основном на основе SOAP

Apache CXF, Spring Integration

Message queuing

RabbitMQ, Spring Integration

Куча кода и бизнес правил в системе, специфических для конкретного клиента

Activiti BPM, Drools

Мобильные клиенты (Android, iOS) для работы с этой системой

Найти тех, кто шарит в теме и заказать у них. Мобильные дела с серверным интерпрайзом - две большие разницы и тех, кто делает и то, и другое найти трудно.

Отчёты

Jasper Reports

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

это очень сумрачно

это надо писать капсом и болдом. столько дебильных багов как в жбоссе я еще нигде не видел.

vostrik ★★★☆
()

средства для тестирования

в основном определяются по месту. JUnit/NUnit, webdriver для вебни, дальше в бэкенд обычно клепается свой фреймворк с использованием своего же кода.

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

А что не так с рестом, если не секрет?

С рестом всё замечательно, он просто не подходит, т.к. обычно в транзакции происходит гораздо больше чем запись/сохранение/удаление одной сущности. Рест отлично подойдёт для бложека с комментариями, но он мало пригоден для приложений с серьёзной логикой на бакэнде.

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

Я последние года два ничем кроме IDEA не пользуюсь. Она платная, но самая отполированная и фичастая. И своровать, если очень хочется, не сложно.

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

Вы под REST понимаете «тот самый» REST или просто вызов HTTP-методов по урлам с JSON'ом или XML'ем в теле?

Если первое, то понятно, если второе, то ума не приложу, что вместо использовать для публичного API.

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

Вы под REST понимаете «тот самый» REST

REST это REST

вызов HTTP-методов по урлам с JSON'ом или XML'ем в теле?

Это называется JSON/XML-RPC, и да, именно его я бы и предложил использовать.

Есть ещё и SOAP и по идее с ним тоже можно работать из жаваскрипта.

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

SOAP

Я с ним много работал, в том числе в виде СМЭВ'а, и имею сказать, что предпочёл бы больше никогда с этим не связываться. Особенно из языков и платформ, для которых нет старых, матёрых библиотек для работы с SOAP. Да и даже там, где они есть, interoperability до сих пор боль: SOAP от .NET и SOAP от JAVA EE зачастую отличаются и плохо контачат. А ведь сколько лет прошло с появления стандарта.

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

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

Тем не менее если

Куча интеграций с другими конторами, в основном на основе SOAP

то может оказаться проще подёргать вызовы прямо из клиента.

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

С рестом всё замечательно, он просто не подходит, т.к. обычно в транзакции происходит гораздо больше чем запись/сохранение/удаление одной сущности. Рест отлично подойдёт для бложека с комментариями, но он мало пригоден для приложений с серьёзной логикой на бакэнде.

Что мешает использовать рест для гораздо большего, чем запись/сохранение/удаление одной сущности? Ты рест изучал 30 секунд что ли? Почитай серьёзную литературу, там всё описывается.

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

Что мешает использовать рест для гораздо большего, чем запись/сохранение/удаление одной сущности?

Гипотетически - ничего, практически - необходимость в дополнительных телодвижениях для реализации всего этого в REST стиле. Я же не говорю, что этого сделать нельзя. Просто буковка Р обычно имеется только у клиента, поэтому вместо того что б прикручивать её к серваку проще использовать с клиента РПЦ и не тратить время.

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

делать API как хочется.

А для чего делать АПИ как не хочется? Обычно оно как-то само появляется.

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

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

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

Не совсем понимаю в контексте мобильной разработки.. Как андроид с сервером общается, если не рест? и чем это лучше/хуже реста?

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

Как андроид с сервером общается, если не рест?

Можно через тот же SOAP, например, https://code.google.com/p/ksoap2-android/

В своё время приходилось использовать именно такой подход. Немного костыльно, больно, приходилось патчить KSoap (какая-то хрень с fault'ами, но это было давно и неправда, возможно, сейчас там всё уже хорошо), но оно работало (в конечном счёте, должен заметить, без особых проблем). Если бы тогда пришлось писать сервисы с нуля, я бы может не стал с этим связываться, но в нашем случае нужно было стыковаться с тем, что уже есть.

и чем это лучше/хуже реста?

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

runtime ★★★★
() автор топика

Имхо, сейчас тенденция ухода от java к скале в вебне. Пишут на Play, про spring уже сто лет не слышал, имхо, он уже жутко устарел, тонны xml, много декларативщины.

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

про spring уже сто лет не слышал
он уже жутко устарел, тонны xml

Иногда лучше жевать.

Уже сто лет как XML можно не писать, а конфигурировать через Java или Groovy.

Спринг живее всех живых. Развитие не останавливается, постоянно запиливают новые фичи.

Для Java-only разработки бизнес-приложений не так много современных, но проверенных временем, вещей, и спринг со всей экосистемой подпроектов - одна из них.

migesok
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.