Всем привет
Помню была либа, чтобы мокать системное время в юнитах и не ждать реальных таймаутов например в Future::get
Напомните, плиз, что за либа была или что-нибудь в тему накиньте

закинь, пжлст, потом информацию в чатик о моках для системного времени, как найдешь

Дайте сеошнику по голове, он не проснувшись линку оформлял)

"фиаско"

Почему?

Что почему?

Из-за роста нагрузки на системы занятости, в США потребовались специалисты в COBOL. И представляете, их не могут найти.  В штате Нью-Джерси количество запросов на пособие по безработице возросло на 1600 процентов за последние несколько недель. От этого система занятости начала трещать по швам, и надо бы обновиться, но есть проблема: ПО на мейнфреймах написано на языке COBOL и его не трогали 40 лет. Самому языку COBOL 61 год, а значит те, кто его изучали, сейчас находятся в основной группе риска, в связи с эпидемиологической обстановкой и вряд ли они последние -дцать лет занимались упражнениями в этом языке. Говорите у вас проблемы с legacy-кодом?

Всем привет
Помню была либа, чтобы мокать системное время в юнитах и не ждать реальных таймаутов например в Future::get
Напомните, плиз, что за либа была или что-нибудь в тему накиньте

Ну вообще это вроде на PowerMock похоже, но так-то лучше юзать везде в объектах Clock и в тестах его подменять

Если я правильно помню у себя такую проблему - ни в Future, ни в CompletableFuture джавовые не подкинуть свои часы.

неее, ну с powermock ты можешь статику всякую переопределять и классы корячить - можно на метод поведение свое повесить

Что почему?

Это да, Powermock-то любую проблему может решить, если очень запариться (всё-таки тогда надо лезть вглубь и искать обращение к времени внутри этих классов если оно вообще есть). Но будем честными, хотелось бы проще (как пример в Котлине решение для корутин например сделано - https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-test/kotlinx.coroutines.test/run-blocking-test.html)

Почему hiring freeze в нынешних условиях это фиаско?

автор - ты