Какие есть реальные преимущества написания Rest API на Java?

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

Зачем сторонние либы покрывать тестами? Это лежит на плечах разработчиков этих либ. Покрывать тестами надо свой проект.

Рано или поздно оно сломается, и без тестов ты об этом узнаешь

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

Если ты в одну морду пишешь - java не для тебя.

Заблуждение. В java одного spring достаточно для 90% задач + maven с его кучей всячины.

Покрывать тестами надо свой проект

Его и надо покрывать. Только бычно, если твой проект сам не библиотека, 100% покрытие бесполезно. Но когда у тебя сторонее чёрт знает что используется во всём коде проекта, то тут-то от полного покрытия уже не уйти.

А старая ж не меняется - чего сломаться может вдруг?

Пинишь вплоть до версии патча? Это суперплохая практика. Если нет, то твой аргумнет не работает. По-хорошему пинить вообще нужно только мажор.

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

Пожалуйста, не делай так никогда независимо от того, на чем ты пишешь! Если уж дошло до того, что месишь SQL врукопашную то лучше конструкции типа:

select col_a,col_b,col_c from my_awesome_table
where 
     (#PARAM1 is null OR col_a=#PARAM1)
AND  (#PARAM2 is null OR col_b=#PARAM2)
AND  (#PARAM3 is null OR col_c=#PARAM3)

где #PARAM1,#PARAM2,#PARAM3 это параметры prepeared statement-а, но лучше использовать готовые библиотеки если тебе не нужно от РСУБД что-то «изысканное». С другой стороны, если потребность извращаться таки присутствует то тут уж лучше профессиональный DBA-шник и хранимый объект.

Ну и раз уж начал, то переданное в order clause может быть воспринято РСУБД как запрос, а не как данные даже при использовании prepeared statement-а. Поэтому сортировки лучше вообще наружу не выставлять или валидировать их нормально.

По поводу ORM-ов: а чем обусловлена нелюбовь? Мне кажется, что для относительно небольших объёмов данных и типовых CRUD-ов - то, что доктор прописал.

Попробуй это на ORM напиши.

Зачем, если речь о квери-билдере?

Так и делаю. Зато знаю что именно делает запрос, потому что сам его пишу и оптимизирую.

Так в квери-билдере и нет никакой магии. Это просто по сути обертка над конкатенации строк, делающая код более читабельным. Сам запрос понятен, но его можно и вывести, чтобы потом оптимизировать, индексы в базе делать. Что-то типа такого, в общем:

qb = (new Query())
    ->select('users', 'cars')
    ->from('users')
    ->leftJoin('cars', 'car_id');
if (carNumber != null) {
    qb = qb->andWhere('cars.number', carNumber);
}

if (carWeight != null) {
    qb = qb->andWhere('cars.weight', carWeight);
}

users = em->execute(qb->getSql())
print(users[0]->cars);

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

Есть подозрение, что ты не мне хотел написать, потому что я руками запросы не собираю.

Пинишь вплоть до версии патча?

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

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

Я не говорю, что тесты вообще не нужны. Я говорю про этот фетиш под названием «100% покрытие».

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

то тут-то от полного покрытия уже не уйти

И опять-таки даже так 100% покрытие бесполезно. Оно всегда бесполезно, потому что код с 100% покрытием ничуть не более надежен, чем код с 80% покрытием. И без разницы, юзаешь ты сторонние либы или нет, они вообще ж никакого влияния на это не оказывают.

Пинишь вплоть до версии патча? Это суперплохая практика.

Пиню мажор, конечно. Патч и минор не влияют на обратную совместимость. Патч - это фикс, а минор - новая фича. А вот мажор, да, совместимость ломает. То есть если мажор запинен, то ничего ломаться не должно. Если, конечно, разраб либы не упоролся и не пометил мажорное изменение патчем.

Твоя простыня – те же яйца, что руками писать, только в профиль.

Но тут ты все равно не знаешь что под капотом. Там все равно магия. И эта магия есть generic код. То есть оно всегда генерирует самый медленный вариант запроса и так, чтобы работало у всех. Руками ты можешь изгаляться вприсядку при должном знании sql и ускорять свои запросы в тысячи раз. Пример: сделай мне window funktion из mysql с помощью ORM или query builder для решения groupwise maximum проблемы. Будешь волосы на попе рвать неделями. А я за час напишу, в прод выложу и пойду пиво пить.

Все эти «100% покрытие, clean code, use ORM» и прочее макаки пишут, а не те люди, которые отвечают за свой код.

Ах да, чуть не забыл самое главное. В Spring тот самый query builder это обычно Spring Data JPA. Адовое говнище из преисподней. Я как-то пытался его заюзать, так оно на 1 (одииин) запрос sql генерирует 10 (десять, мать твою!) запросов. И так КАЖДЫЙ раз. Делаешь 10 запросов, получаешь 100. Круто, да?

Prepared statement никто не отменял, даже если месить руками.

А ORM приравнивается к индусокоду.

Ну ты уже в крайности вдаешься. Я не говорю, что КАЖДЫЙ запрос надо квери-билдером ваять) Но и все запросы собирать руками тоже такое себе

Как квери-билдер может генерить 10 запросов? Квери-билдер собирает строку. Одну.

Ладно до минора, я сам так в основном делаю, но патч-то пинить как-то совсем не хорошо.

Да, да, не оказывают. Сломали тебе библиотеку, ты обновился, тесты упали.

То есть если мажор запинен, то ничего ломаться не должно

Какая-то феерическая наивность.

Квери-билдер собирает строку. Одну.

Это ты так думаешь. Абсолютно безосновательно думаешь. Или веришь, кто тебя знает.

В java мире нет просто квери билдеров, а есть монструозные обертки. Читай выше про spring data.

А зачем тащить за собой 10 разных видов запросов (читай библиотек)? JDBC Template может биндить сразу в объект или билт-ин тип типа Double, а можно ручками.

Ясно, буду знать. Я думал просто, что там типа такого что-то есть

Представим, что эта библиотека - некий клиент для какого-то сервиса, делающий http-запросы (обертка над неким API). Чтобы протестить свой, код, использующий эту либу, в любом случае будешь писать mock-обертку, чтобы при выполнении тестов реальные http-запросы никуда не делались. А если так, то твой тест не гарантирует тебе ничего при поломке обратной совместимости в этой библиотеке.

Это классика, так и свой код нормально протестить не можешь. Посмотри в начало треда, речь ведь не об этом, там мне предложили аж для чтения файлов сторонние библиотеки использовать.

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

Убеждай себя дальше. Ездить на мерседесе глупо, он слишком отвлекает от вождения совими плюшками. Жить в частном доме накладно, снег же убирать надо. А вот жрать говно вот это по-нашему оууйее. Что? Попробовать пожить в доме и погонять на мерсе? Нее, говно оно уже мое, а то оно что-то нинашенское, угу, тысяча причин.

Жить в частном доме накладно, снег же убирать надо

Именно так. Купи себе дом сначала, потом пообслуживай, потаскайся в центр с окраины, тогда уже мне и расскажешь. А я пасс, мне хватило.

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

Например, в каких случаях API лучше пилить именно на Java?

В случаях когда весь остальной функционал приложения на Java?

лишь показывают твою некомпетентность.

Мою-то? Ну ты и клоун.

именно многопоточность из коробки и есть основная киллер-фича Го

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

но, исходя из моего опыта разработки на Php/Python/Go, могу сказать, что писать запросы в базу руками - то еще извращенство

энекий вайтишник, который не смог разобраться с RDBMS и освоить SQL сейчас нам всё объяснит исходя из опыта Php/Python/Go

Пинишь вплоть до версии патча?

Внезапно, имеющая место быть практика даже на Node.

Считаешь её нормальной?

В целом, да, проще написать ручками. Но как ты поступишь, если тебе нужен bulk insert, или когда нужно из ответа объект собрать? Развлекалова полные штаны.

Жить в частном доме накладно, снег же убирать надо.

Частный дом – это шиздец. Считай вторая работа.

Хз, я просто локфайлы коммичу, а не фиксирую версию, убирая ^ в package.json

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

https://www.jooq.org/doc/3.13/manual/getting-started/tutorials/jooq-in-7-steps/jooq-in-7-steps-step5/ ?

Или http://www.querydsl.com/ ?

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

А как вы обеспечиваете воспроизводимые сборки?

Воспроизводимость как таковая не особенно ценна, если есть хорошее покрытие.

А в случае когда это действительно принципиально, нужно где-то у себя кеш держать. Иначе хрень это, сторонние репозитории ты всё равно не контролируешь.

Jdbc template уже осиль как и тот выше…

А почему именно на spring + hibernate ? Лучше на akka http

Оно настоящий bulk insert в итоге сделает или просто кучу единичных инсертов в транзакции?

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

джаву и не берут - она жрёт как не в себя.

Ога, лучше сразу C++ брать.

Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной лишь бы не писать на джаве.

Глупость несусветная. Скала например вообще совершенной другой, самостоятельный язык со своей парадигмой, но с интеропом с Java. С таким же успехом можно вообще любой язык привести в качестве доказательства ущербности Java. Типа «Nim был запилен лишь бы не писать на джаве», смысла в твоем высказывании примерно столько же.

Что касается JVM, ну так есть еще perl на JVM. Язык Perl ведь не был «запилен лишь бы не писать на Java». Есть scheme на JVM (забыл как называется). Это лишь доказательства успешности самой идеи JVM и ее качества.

Если бы у тебя была хоть капелька мозгов (ну и представлений о вопросе по которому высказываешься), ты бы в доказательство своего (слабо сформулированного) наезда на Java привел бы C#.

Что касается котлина. Факт его существования твой наезд никак не доказывает. Котлин это бесполезный язык. Он добавляет необходимость разобраться с его синтаксисом (это не сложно, но зачем профессионалу замусоривать мозг и тратить на это силы?). Он добавляет новый синтакс который понимают не все редакторы/IDE, не все инструменты документации, не все статические анализаторы и т.д. и т.п. Он добавляет новый компилятор в проект, в систему сборки. При этом он не решает вообще никакой проблемы Java и ничего не добавляет. Вообще не понимаю, как люди купились на этот котлин.

Данный инструмент входит (тык) в NIO.2, начиная с релиза Java SE 7.

Ради решения этого и сделали поломку с JPMS в Java 9. Впрочем, эти проекты по кодовой базе настолько огромны, что уже действительно необходимо держать группу поддержки только на разрешение зависимостей. В остальном - ничем не хуже Go.

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

Твоё непонимание ситуации с котлином контр-аргуметом не является. Джавята от него в восторге, иначе так резко бы не перепрыгнули.

Пинишь вплоть до версии патча? Это суперплохая практика. Если нет, то твой аргумнет не работает. По-хорошему пинить вообще нужно только мажор.

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

Подключенные к интернету проекты с плавающими номерами библиотек - это вообще не нормально, а то что это сегодня чуть ли не стандартная практика в индустрии - так индустрия на 90% состоит из полудурков типа тебя.

Некоторые и сегодня в Java проектах просто jar кладут в lib и получают стабильный самодостаточный проект.

Дурачок здесь ты, если не понимаешь почему нельзя пинить патчи.

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

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

Глупенький, ты сел вот в лужу, про стратегию запел. Это к делу не относится.

Вот это твое высказывание: «Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной лишь бы не писать на джаве.» - оно как было глупостью, так и осталось.

Твоё непонимание ситуации с котлином контр-аргуметом не является. Джавята от него в восторге, иначе так резко бы не перепрыгнули.

Во-первых, является.

Джавята от него в восторге

Какие? Кто? Полудурки типа тебя? Сколько их? Вайти-вайтишники на андройде вообще слабо соображают, что делают.

Короче, ты джаву видел только по телевизору. Представление о вопросе имеешь только приблизительное. Но «мнение имеешь».

Эта многословность сильно автоматизирована. Тем не менее, читать Java проекты начинающим куда проще, чем тот же Kotlin. Особенно, когда в последнем появляются Extensions. Вот от чего у меня люто горит, так это от способности разработчиков Kotlin’а впихнуть что-то, с чем гадать потом будешь: только что ведь была эта функция в классе, куда она делась?

Это к делу не относится

Напрямую относится, показывает нерелевантность твоего лепета про шарп.

Котлин вообще мерзость на мой вкус, если что. Но мощный отток на него — факт.