Подключите https://github.com/Kotlin/kotlinx.coroutines/tree/master/integration/kotlinx-coroutines-jdk8. Экстеншен для CompletionStage живёт там

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

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

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

suspend fun getData(httpClient: HttpClient, url: String): String? {
    val httpRequest = HttpRequest.newBuilder().uri(URI.create(url)).build()
    return httpClient.sendAsync(httpRequest, HttpResponse.BodyHandlers.ofString())
           .await().body()
}

val httpClient:HttpClient = HttpClient.newBuilder().build()
val result = measureTimeMillis {
    runBlocking {
        (1..10).toList().map { async { getData(httpClient, "$URL/$it") } }.awaitAll()
    }
}
println("Time for requests: $result")

Если используете logback, обратите внимание на вот эту статью — https://habr.com/ru/post/524130/. Корутины подчас генерят исключения с циклами, что может быть ВНЕЗАПНЫМ сюрпризом.

Чуть больше информации (специфично про корутины) — здесь

Понятно, спасибо большое! Было бы круто иметь что-то подобное в виде опен сорс проекта, чтобы не переизобретать велоспеды заново, но это так — мечты :).

Наверное, последний вопрос — реализацию отслеживания зависмостей вы тоже делали силами modernizer'а? Если да, то какие плюсы для себя видели по сравнению с тем же renovate который можно on-premise развернуть (ну кроме опять же унификации инструмента хоть и ценой поддержки своей собственной реализации)?

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

Выглядит что эта часть содержат наибольшую "добавленную стоимость" по сравнению с распространенными системами типа dependabot/renovate.

Интересно насколько встроенные плагины бута справляются с правильным переиспользованием слоев в случае CI системы и большого числа агентов. До версии 2.3 с её инструментами сборки образов надо было приложить некоторые усилия для этого. Чуть больше года назад писал про это

Ещё немного некропостинга — оказывается с улучшенной поддержкой расширений, не xml'ем единым: https://github.com/takari/polyglot-maven

Выглядит очень интересным вариантом для случаев, когда супер гибкости сборки не требуется и единственное чего хочется — большей лаконичности и компактности от pom файла

Если бы не пример с использованием aws cli без --endpoint в статье, я бы предположил, что это кусок облака mail.ru. У них есть s3-совместимое хранилище (со своими особенностями, но для простых операций не отличить)

Когда изучали проблему невоспроизводимости на билд агентах, эта версия рассматривалась и даже некоторое время после исправления настоящей проблемы использовали строчку find . -exec touch -t 200001010101 {} \; на распакованных файлах, но позже выяснили что она ничего не улучшает (по крайней мере на тех сценариях что у нас есть).
Jib наверное стоит действительно посмотреть, выглядит интересно. Спасибо за наводку.

Основная причина — преемственность статьи из спрингового блога. Я специально не трогал базовый образ, чтобы не вводить новых сущностей.
В целом вопрос выбора базового образа вопрос отдельный, но статья больше про оптимизацию разницы между образами, как вы можете видеть из графика в последнем разделе — какой бы базовый образ не был, мы получаем очень мелкие диффы. Это конечно не отменяет необходимость первичной загрузки на сервера, но при условии что прилаг много и все они шарят базовый образ его загрузка будет выполнена один раз.

Можно но раз localstack берет на себя вопросы портов, хоста и прочего, имхо это должно делаться в модуле который поддержку localstack в testcontainers и добавляет.
Решение с ENV лишь чуть-чуть элегантнее чем переписывание очереди в полученном queueUrl

Стандарта нет, все зависит от дизайна API и задач стоящих перед API. С точки зрения стандартных операций, есть OPTIONS метод, ответ на который должен содержать список доступных HTTP методов которые можно выполнить над ресурсом. В некоторых случаях это может помочь, но если у вас логика сложная то это может быть слишком "грубо" — например вы хотите позволить клиенту делать PUT запрос с определенными данными, но запрещать передавать другие данные. Как вы понимаете, через OPTIONS этого будет сложно достичь.

Могу сказать о своем опыте: если речь идет о "единичных" ресурсах, то отсутсвие ресурса выражается в отсутсвии ссылки на него. С коллекциями мы считаем что они всегда есть, но в случае чего пустые.

Action'ы мы выставляем в основном в тех ресурсах, к которым они относятся, но бывают и исключения. Из последних примеров — есть ресурс asset — содержащий мета-информацию и у него есть action для загрузки бинарных данных для него, естественно указывающий на другой URI. Так же и с созданием элементов для коллекций — action всегда присутсвует в самом ресурсе-коллекции, но в некоторых случаях мы выставляем его в другом ресурсе, если это лучше соотносится с задачами (производительность, логичность с точки зрения семантики ресурса и т.д.).

Цитату из диссертации приведете?

Не надо пожалуйста в таком категоричном тоне про темплейты. В API Craft мейл листе люди обсуждают реализацию API с использованием html, ведь он имеет все для этого необходимое.

Нестандартно, но не запрещено :). Другое дело, что клиентов под это дело мало, но если кто реализует такое API оно будет полностью соответсвовать REST подходу.

Я согласен что REST это про ресурсы, а не про набор заранее определенных вызовов, как в случае с RPC.

Но я не совсем согласен со следующими моментами:

1. Семантика методов. В первом комментарии вы сказали что "GET, POST, PUT, PATCH, DELETE строго определена семантика".

   
   
   1. Это так для всего кроме POST. Как я указывал ранее, в актуальной спецификации HTTP у post'а семантику определяет сам ресурс и REST тут ничего не меняет, потому что REST не меняет ограничений протокола.
   
   

   Я не спорю что много задач можно решить чисто CRUD подходом, вводя самоограничение, что POST мы используем только для создания ресурса, но не стоит обобщать это на все API и на протокол HTTP как таковой. REST, как принцип, нас совсем не ограничивает — он предписывает серверу сообщать клиенту состояние ресурса (и что с ним можно делать) и не нарушать семантику протокола который используется между ними используя его возможности по назначению. Указывать явно или не указывать метод для выполнения действия уже вопрос реализации.

   
   

2. "HAL — язык описания отношений".

   
   
   1. Вообще это формат представления ресурса у которого в спеке четко прописано где находятся ссылки. И форматов подобных ему достаточно много. Отношения описывают линки, семантика которых задаётся relation'ом. Тут эти форматы ничего не изобретают, используя уже известные конструкции из html'я и atom фидов.
   2. То что там нет методов не истина в последней инстанции, а просто виденье его создателя — об этом Майк Келли лично говорил на конфе API Craft в 2014 году.