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

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

Весьма ценна, если речь идет о продукте, который нельзя выкатывать каждый день, да даже каждый месяц. Выкатил заказчику версию, а через 6 месяцев получил фидбек с каким-нибудь трудновоспроизводимым багом. Необходимо откатиться, воспроизвести ошибку, пересобрать с добавленным журналированием, если не хватает, повторить её снова. Найти багу. Починить её «на месте», выкатить патч версию для старого релиза. Пропатчить все последующие версии. Обновить у заказчика старую версию (потому что новая ещё не готова к интеграции с данным заказчиком).

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

Дурачок, какие патчи? Патчи накладывают (либо приклеивают). У библиотек есть версии. Ну и почему же «нельзя пинить патчи»?

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

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

Ну, современный write-only потомок Java. Что-то между Java и Perl с человеческой маской.

Не удивлюсь, если Java впитает в себя какие-то удобные фичи из Kotlin (т.е. Records выйдут из preview, project amber завершится), после чего Kotlin начнёт долго и мучительно умирать. Я не вижу причины, почему язык-паразит, висящий сразу на нескольких «мамках» (JS, Native, JVM), может надолго захватить крупную часть рынка.

Спорным решением при этом будет не выкатить зподним и пропатченые библиотеки.

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

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

Но ведь уже захватил и андроид теперь не отдаст.

А причина тому — разработчик. Кто пилит инструменты (InteliJ), тот и заказывает музыку, как оказалось.

Android - это проблемы политического толка (Oracle), а не проблемы платформы Java.

Тупица тут только ты. Я-то в отличии о тебя десятки проектов выкатил и поддерживал.

Это так называемый «патч» - части версии. Это новая отдельная опубликованная версия.

Если проект зависит от 1.2.3 - значит с ним и работают. Обновление, как я тебе дауненку объяснил уже, делается в рамках отдельной задачи. Но это делается по определенным причинам, в определенное время, и во вне определенных периодов.

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

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

Риальный клоун погромист не в состоянии отревьюить изменение приведшее к бампу патч-версии? Хаха. А ещё, небольшой секрет, даже изменения минора по-феншую не должно ломать API.

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

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

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

Уже давно есть artifactory и nexus, которые умеют работать в режиме кэширующего прокси, в итоге артефакт скачивания с maven central repo ровно один раз, потом уже все тянут из репозитория.

По теме: лучше чем Java full stack ты в 2020 году не найдешь. Спросишь «чем лучше?» – по всем направлениям лучше чем всё остальное. И если кодер попадет под трамвай, следующего можно найти на улице за 5 минут.

C/C++/Rust жрут ощутимо меньше памяти. Также на них можно писать софт-реалтайм приложения, хотя в последних версиях JVM сборщик мусора очень крутой и, возможно, сейчас уже это и на Java можно делать.

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

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

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

А ты контролируй. Не тяни в проект что попало.

Ну и да, в maven central лежит всё. https://repo1.maven.org/maven2/org/apache/maven/maven/2.0/ артефакты 2006 года, например. Поэтому всё прекрасно соберётся и спустя 15 лет. Другой вопрос, что, конечно, до такого лучше не доводить.

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

Если драйвер умеет и правильно настроить (100% случаев, если не макака), то сделает настоящий batch insert. Только это не всем надо откатывать всю транзакцию если 1 инсерт зафейлится.

маппер для объекта тебе всё равно придётся ручками писать

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

Риальный клоун погромист не в состоянии отревьюить изменение приведшее к бампу патч-версии? Хаха. А ещё, небольшой секрет, даже изменения минора по-феншую не должно ломать API.

Это ты уже от безысходности чушь несешь про «отревьюить изменение»?

Короче говоря, ты о программировании ничего не знаешь вообще. От слова совсем.

Кроме того, важна возможность отличать свои эффекты от не своих. Если такая возможность утрачена, то вообще ничего делать невозможно.

не можешь гарантировать, что проект у тебя через год-два соберётся

Че-т не понял, как это оправдывает твое предложение не закреплять версии зависимостей? Ты сам против себя уже выступаешь что ли?

Проект гарантированно соберется и через 300 лет, если у тебя все версии библиотек те же, дурак.

В этом случае он перестанет собираться только если у тебя компилятор или система сборки поменялись.

не можешь гарантировать, что проект у тебя через год-два соберётся

Че-т не понял, как это оправдывает твое предложение не закреплять версии зависимостей? Ты сам против себя уже выступаешь что ли?

Проект гарантированно соберется и через 300 лет, если у тебя все версии библиотек те же, дурак.

В этом случае он перестанет собираться только если у тебя компилятор или система сборки поменялись.

То есть, парировать ты не в состоянии, и можешь только съехать? Ладно. Слив засчитан.

висящий сразу на нескольких «мамках» (JS, Native, JVM) На чем висит язык у которого своей стандартной библиотеки нет, и он зависит от джавовской? И у которого нет собственного обеспечения кросс-платформенности по процессорам и ОС, а есть только джавовская JVM и джавовская опять же стандартная библиотека?

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

что есть у котлина? лвти? так это вредная возможность. у меня 6 месяцев опыта программирования на джаве 8, параллельно использовал новую джаву с lvti - так это антифича, это понятно когда попробуешь. сначала кажется, что вот прогресс. но код с явными типами гораздо понятней и быстрее читается через месяц. а экономии никакой. что экономит этот вар? набор он тоже не экономит, потому как в идее фактически этот лвти встроен, про правой части которую ты набрал левую часть идея сама тебе напишет, те же три кнопки.

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

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

Так генерики такие для обратной совместимости.

Система сборки поменяется в любом случае, не будешь же ты снапшотить окружение перед каждым билдом и хранить это вечно?

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

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

Джаве помогли бы структуры примитивных типов с возможностью размещения их в массивах (над этим работают в оракле), но котлин к этому никакого отношения не имеет.

Inline classes немного помогает.

Джаве бы хорошие дженерики, но этой информации нет и 100% интероп котлин<->жава не получился бы.

Достаточно в объекте хранить Class для каждого generic типа, передавая его в конструкторе. Не сделали, но могли бы. Подозреваю, не сделали потому, что ценность этой фичи не так уж велика.

что есть у котлина

null-safe система типов это самое важное. Также из важного - улучшенная система коллекций, при этом совместимая с Java. На мой взгляд стримы гораздо хуже.

Ну и уйма «сахара». Про каждый можно сказать, что не так уж он и важен, но всё вместе делает программирование ощутимо приятней.

Не убедительно указал, маня, учись усердней.

Квери-билдеры такое же говно. Они строят итоговый запрос сами и ограничены своим узким понимаем и семантики, синтаксиса и структуры запроса, и системы типов. Все эти select()->from()->where() не подходят даже для примитивных select … from … where …, потому что они реализуют 1% SQL и 0% вендор-SQL. Любая такая библиотка, которая захочет уметь чуть больше (2% SQL и 1% вендор-SQL) превращается в непостижимое никаким умом неприменимое в работе говно, которое кроме того начинает просто ломаться, глючить на одних запросах и менять поведение (то есть получившийся SQL имеет другой смысл и результаты) от версии к версии на других.

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

Inline classes

Кажется, это что-то немного другое. Я говорю о «классе» из n примитивных членов, массив «экземпляров» которого будет включать непосредственно сами экземпляры с их членами (и занимать памяти размер_экземпляра x кол-во_эл-тов).

null-safe Проблема NPE преувеличена, на мой взгляд.

Сейчас написание «чего-то» на Java имеет смысл только если:

1. Это кровавый энтерпрайз и ты хочешь чтобы были транзакции, чуство защищённости и всё такое
2. Тебе нужны сложные комбинации разных библиотек (реально дохрена всего понаписано). Это касается и автотестов.
3. Ты знаешь Java лучше остальных языков программирования

Hibernate для работы с БД очень удобная штука, но если у тебя тупо CRUD и при этом на 3 пункта ниже ответы отрицательные, то я бы не советовал. Исключение - когда РЕАЛЬНО надо поддерживать много разных баз данных, но я с таким не сталкивался.

P.S. Отдельно напишу - с точки зрения архитектуры-безопасности можно криво написать на любом языке. И наоборот. Поэтому данную аргументацию считаю не совсем правильной.

Если ты говоришь, что некоторую ценность он всё же несет, то значит так и есть. Но для меня (как для многих других, я уверен) польза от его внедрения не перевесит минусы и затраты, а «действительно важные» недостатки не исправит. Кроме того, двигает его только и исключительно гугл и только по политическим причинам. Почти уверен, что технические достоинства котлина гугл считает ничтожными и не перевешивающими затраты от его внедрения (есть доводы в пользу этого), а джавовское лобби там гораздо сильнее.

Кажется, это что-то немного другое. Я говорю о «классе» из n примитивных членов, массив «экземпляров» которого будет включать непосредственно сами экземпляры с их членами (и занимать памяти размер_экземпляра x кол-во_эл-тов).

Я понимаю, inline classes решают эту проблему для случаев, когда n = 1. В общем случае, конечно, требуется доработка JVM.

Проблема NPE преувеличена, на мой взгляд.

Дело не в проблеме NPE, а в более строгой системе типов. Любой ссылочный тип в программе может либо принимать null, либо не принимать. В Java это не выражается кроме как уверениями программиста и runtime проверками, в Kotlin выражается.

Собственно тот факт, что в Java всё больше библиотек обзаводятся аннотациями Nullable это такая неявная реклама Kotlin, где это всё работает нормально, а не прикручено сверху.

Ну давно уже не только спринг - JAX-RS в помощь. Там такого накрутить можно, что хрен потом поймёшь реальную схему навигации.

Ну и Java-JSON преобразование - это Jackson (FasterXML) без вариантов.

Тот, кто говорит, что на Java код пишется быстрей - никогда не писал на python. С Go не сравниваю - не знаю этой гуглоподелки и учить не собираюсь.

Ну это вы просто не умеете Java готовить - например, такая штука есть - https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

У меня реальные проблемы со сборкой возникли только при переезде с Java 8 на 11. Но там охренеть сколько всего поменялось, самая засада - что jaxb выпилили из jdk.

потому что они реализуют 1% SQL и 0% вендор-SQL

Это вы так про CriteriaBuilder? Напрасно - он дохрена чего умеет. Вот только готовить его сложно.

превращается в непостижимое никаким умом неприменимое в работе говно

сложное - да, но не «непостижимое».

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

Писать-то быстрее, а вот поддерживать и рефакторить — my ass!

У Go проблема с фреймворками, он годится только под микросервисы и конкретные небольшие задачи. А в целом, код пишется быстро и крайне приятно.

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

Так вот, немногословность обладает преимуществом не только в написании, но и в чтении кода. А читать код приходится гораздо чаще, чем писать. И вообще, хорошая большая программа - связка огромного количества маленьких. Можно даже на Javascript писать. :)

У Go проблема с фреймворками, он годится только под микросервисы и конкретные небольшие задачи.

Аналогичная беда у Javascript (npm + node.js) - такого лютого ужаса в библиотеках я нигде больше не встречал.

Писать-то быстрее, а вот поддерживать и рефакторить — my ass!

Рефакторить код на динамическом языке программирования? Сэр, я же не идиот и не самоубийца :))) Хуже этого только рефакторить perl-овый скрипт.

Тот, кто говорит, что на Java код пишется быстрей - никогда не писал на python.

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

Какой-либо рефакторинг (даже не меняющий логики) в питонах возможен только для микропрограмм на 500 строчек. Потенциал для инструментов статического анализа в python нулевой, потому даже питонский компилятор, если бы таковой существовал, не знает о программе ничего вообще.

Слишком много ситуаций, при которых python-IDE почти ничего не может подсказать. У Java всегда полное понимания кода IDE (кроме участков с рефлекшеном). Из-за этого само написание программы в С#/Java многократно быстрее чем на питоне.

Что касается вербозности, то преимущественно эти страшилки не имеют отношения к действительности, так всё это пишет IDE.

По документации Java и python - две противоположности. У Java лучшая в индустрии (после продуктов MS может быть), у python - самая плохая, уступает даже php. Скажите еще что документация не влияет на скорость разработки.

То есть так говорят только люди, которые в редакторе vim посчитали буквы, которые нужно печатать на python и на Java и сделали из этого вывод о скорости разработки. Но если бы человек подумал хотя бы на одну минуту вперед то обнаружил бы, что ситуация уже обратная.

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

Кто-то тут никогда не видел питон. 90% из поможет избежать даже pylint прямо «из коробки», и это не 99% только из-за метапрограммирования. Ещё этак 5% покроет MyPy, если упороться и идеально расставить типы.

Поэтому в нормальных языках есть linq, а в gовноланге и подобных нему - нет и никогда не будет.

К чему рабам дары свободы?

Бульк.

ЧичерХеральт

Не C++, а Go, он заточен под многопоточность и сеть. Его и создавали под REST - под большее он не очень удобный

linq - это какая-то калька на orm, причём очень специфичная. В питоне, между прочим, лучшие ORM, после которых смотреть на всякие linq можно с улыбкой

На жабке всё хорошо, пока либы покрывают твои хотелки. Шаг влево и начинаются блудные танцы. Ява сейчас в том состоянии, когда пишут на спринг+гибернейт, а не на яве. Как уже сказали, куча фуллстак-макак, следовательно, куча говнокода, большая конкуренция на рынке труда и работодатель уже не горит желанием платить какие-то деньги. Память жабка жрёт так же, как и всегда, стектрейсы всё длиннее, чуть что набирать надо как машинистка или делать закшварную кодогенерацию. Сообщество всё больше походит на секту, дрочат там на свой многопоток, ООП и мегапроекты.

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

Именно спринг+гибернейт - только если у тебя тупой crud.

Если речь о JS, нетипизированная параша

Вы просто не умеете его готовить всю жизнь сидите в своём ООП и не способны мыслить как-то по-другому. Такие люди приходят в js и начинают ныть, что им нужен typescript. Языки с динамической типизацией отличаются тем, что не ограничивает программиста делать вещи как-то по-особенному. На js, например, всякие вещи с рефлексей и декларативщиной делаются легко и непринужденно. Парадигма языка не обязывает тебя наяривать в присадку на ооп. Динамика это вообще единственное место, где можно что-то делать отличное от default.

на Java писать код раз в 5 быстрей

На js пишется 1 строчка там, где на жабке унаследуют два класса, напишут 4 и сделают абстрактную фабрику контроллеров. Ну может в будущем это и окупается, не знаю.

в 10 раз меньше багов.

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

пишут на спринг+гибернейт, а не на яве

Это печально. Питонисты пишут на джанге дефакто. Фронтендеры пишут не на HTML/CSS/JS, а на бутстрапе и реакте. Пхпшники пишут на симфони и ларавеле. Люди тратят время и силы на бесконечное изучение десятков меняющихся фреймворков, причем очень субъективных и далеко не идеальных.

Причём здесь Go? И о чём ты, «по-этому» это ты вообще про что? Анонимусов пора начинать проверять на содержание алкоголя в крови при входе на форум.