Планировщик задач - это целая либа энивей

Всем привет. Есть кто работает на MacBook M1 ?

Nometa.xyz и  желательно на тему jvm

Я и собраюсь задавать вопрос на тему JVM. Просто хотел спросить как вам удалось установить джаву на макбук m1

Или спец сборки, в чате вроде ссылка уже была. Если ничего не путаю

Если что, это сборка Microsoft

Сори не так прочитал

Мне было просто лень писать с телефона, что правильными ответами будут все возможные непустые подмножества {2, 5, 6, 10}. Думаю что в чате @pro.jvm это всем очевидно (мы же не в @javastart). Мы с Николаем отлично друг друга поняли. Если мне попадётся интервьюер который не возьмёт меня на работу сказав что мой ответ неправильный и не поговорив об этом, я буду только рад что не попаду в такую компанию.

подскажите как можно испольховать стрим внутри стрима? хочу проверить являются ли строки массива А подэлементами массива Б. я могу проверить только являются ли строки массива А подстроками одного стринга.

Эээ, да так же, как и вне стрима.

А вообще вопрос для @javastart

понял, ушел в старт

https://webtide.com/do-looms-claims-stack-up-part-1/
https://webtide.com/do-looms-claims-stack-up-part-2/
2 статьи как разработчики jetty ранную версию лума пробывали и вот тут
https://old.reddit.com/r/java/comments/kmn6m3/do_looms_claims_stack_up_part_1_millions_of/
очень годный тред с комментами от Рона (тех лида проджекта лума)

Всем привет! Никто не сталкивался с деградацией производительности при апгрейде spring boot с 2.3.5 до 2.4.1?
Суть - есть консольное спринг-бут приложение, только базовый стартер, environment=none. есть интерфейс, у которого ~150 реализацией, проаннотированных как

@Component
@Primary
@Scope("prototype")

Есть конфигурация, выступающая своего рода object provider, получающая инстанс _конкретного_ класса:

@Configuration
@RequiredArgsConstructor
public class DiagnosticConfiguration {

  private final ApplicationContext applicationContext;

  @Bean
  @Scope("prototype")
  public <T extends BSLDiagnostic> T diagnostic(Class<T> clazz) {
    return applicationContext.getBean(clazz);
  }

}

На 2.3.5 ~15000 инстанцирований бинов (разных типов) через конфигурацию занимало 12 секунд чистого процессорного времени. Простой апгрейд до 2.4.1 увеличивает это время до 75+ секунд. На flame graph видно, что львиную долю стал занимать CommonAnnotationBeanPostProcessor.postProcessProperties(PropertyValues, Object, String), хотя на 2.3.5 он вообще в flame graph не показывался.

Что изменилось? Куда можно покопать?

flame graph с проблемным местом:
https://i.postimg.cc/JhNfXY50/image.png

выкачать исходники и посмотреть git diff?

ну и посмотреть различия в flame graph - и посмотреть где именно начинаются различия

Неплохой план. С какого модуля начнёте?)))

Поэтому я и сказал что сначала бы посмотрел на изменения в flame graph

где начинаются изменения - с того модуля и начинал бы