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

В Go как раз всё лаконично и есть нормальные батарейки в отличие от.

и есть нормальные батарейки

Например?

Да хотя бы простейшая фича — вычитать файл целиком, она есть в стандартной библиотеке, и это дофига приятно.

Представь стандартную библиотку питона, только без мусора, лучше вдвое и с байтами. Это Go.

String FileUtils.readFileToString(file)
byte[] FileUtils.toByteArray(file)

А чем они хуже?

Но я посмотрел, действительно неплохо. Правда Java сильна сторонними библиотеками как мне видится.

язык без исключений не может быть лаконичным.

тем более го вообще уродец без дженериков и нормальной поддержки многопоточности (в чем Java лидер).

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

И вот так на каждый чих что-то извне тащить, класс, да?

Насчёт говноязыка согласен, не надо его использовать. Но Go ещё хуже.

Э-э-э… мсье сторонник плоских неймспейсов?

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

Maven, ant? Не, не слышал.

А, так ты жертва 100% покрытия и прочего Clean Code… ок

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

Типичный Goшник detected.

В нормальных проектах не делают импорт по гитхаб-урлу. Там в проект добавляют конкретные версии. Которые через год-два не поменяются.

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

Что мешает зафиксировать версию в go.mod?

это такой символ веры из мира динамически и слабо типизированных языков

Ну как бы те же проекты на Java активно покрывают тестами. В ней слабая типизация?

Ты, кажется, не понимаешь что такое «сторонние библиотеки» в java мире. Это очень хорошо оттестенный код. Сделан он для того, чтобы не строили велосипедов. Через maven я обновляю версии примерно раз в 2 года, ито хз зачем. Просто чтобы up to date было. Итак все работает.

Например: покрывать тестами какой-нибудь apache poi нет надобности. У него огромное комьюнити и багов там почти нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Весьма ценна, если речь идет о продукте, который нельзя выкатывать каждый день, да даже каждый месяц. Выкатил заказчику версию, а через 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 ровно один раз, потом уже все тянут из репозитория.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inline classes

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

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

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

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

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

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

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

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

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

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

Самое забавное – это то, что я сталкивался с практически идентичной ситуацией.