Слайды останутся с вами

https://oleg.guru/highload23

fill

Олег Чирухин

🥑 Деврел в Axiom JDK
axiomjdk.ru

⚡Продюсер в Failover Bar
tg: @failoverbar

💡Основатель Telegram-сообществ
tg: @javawatch
tg: @graalvm_ru
tg: @archlinux_ru

➿Habr-блоггер: https://habr.com/ru/hub/java

Safe Harbor

Всё содержимое этого доклада может быть художественным вымыслом или неправдой. Поэтому, нужно думать своей головой и не верить докладчику на слово.

Если вы пытаетесь внедрить решения и знания, полученные из этого доклада, вам стоит нанять профессионалов. Они расскажут, что стоит использовать, а что — нет.

Идея слайда: Aleksey Shipilëv
Википедия: Safe Harbor

Как создается Java

Как происходит магия, и как в этом поучаствовать

В этом докладе

  • Почему эта тема важна?
  • Что такое OpenJDK?
  • Из каких проектов он состоит?
  • Как поучаствовать
  • Java в России

Популярность ⚡

2017 2018 2019 2020 2021 2022 Язык
65% 64% 69% 70% 69% 65% JavaScript
60% 55% 61% 61% 60% 54% HTML/CSS
32% 41% 49% 55% 52% 53% Python
42% 47% 56% 56% 54% 49% SQL
47% 51% 50% 54% 49% 48% Java

JetBrains The State of Developer Ecosystem '22

Любовь ❤

Проценты Язык
44% Kotlin
39% C#
38% Python
36% Rust
34% Java

JetBrains The State of Developer  Ecosystem '22

Java повсюду

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

— Стивен О'Грейди, главный аналитик и сооснователь RedMonk

  • 69% разработчиков пишут на Java
  • 60 миллиардов активных JVM
  • 34 миллиарда JVM в облаке
  • 98% компаний из Fortune 100 нанимают джавистов

Runtime

  • Virtual Threads
  • Foreign Function & Memory API
  • Vector API
  • Generational ZGC
  • Prepare to disallow Dynamic Loading of Agents
  • Deprecate the Windows 32-bit x86 Port for Removal

Language

  • Record Patterns
  • Pattern matching for switch
  • Scoped values
  • Vector API
  • Structured concurrency
  • String templates
  • Sequenced collections
  • Unnamed patterns and variables
  • Unnamed classes and instance methods
  • Key encapsulation mechanism API

Java повсюду

  • Документооборот
  • Банки
  • Связь
  • Медицина
  • Наука
  • Транспорт
  • Энергетика
  • Электронное государство

Ускорение выпуска релизов

Что такое OpenJDK?

OpenJDK — это место для совместной разработки
Open Source реализации Java Platform, Standard Edition
и связанных с ней проектов.

OpenJDK.org

OpenJDK — место,
где создают основу Java

  • Группы, Проекты, Списки рассылки, Вики, JEP-ы
  • Разработчики по всему миру
  • Новые фичи должны выглядеть, как будто всегда существовали
  • Очень высокая планка входа
  • Спецификацией их проверкой занимается JCP

Группы

  • Работают вместе для достижения общих целей
  • Примеры: compiler, core-libs, hotspot, security, networking, JVM, 2D graphics
  • Группы поддерживают проекты
  • Роли: member, lead

Проекты

  • Вместе разрабатывают конкретные артефакты, которые поддерживаются 1+ группами
  • Примеры: JDK, JDK Updates, Amber, Loom, и т.п.
  • Списки рассылки, вики, репозитории исходного кода
  • Роли: Author, Commiter, Reviewer, Lead

Управление

Пять членов правления

  • Президент (назначается Oracle)
  • Вице-президент (назначается IBM)
  • Глава проекта OpenJDK
  • 2 выборных участника сообщества

Свод правил управления

https://openjdk.org/bylaws

Пульс GitHub

  • >1000 участников вообще
  • ~20 групп
  • ~75 проектов

Последний месяц

  • 200 авторов
  • 401 коммит

Роли

Автор → Коммитер → Ревьюер → Лид проекта

Автор

  • Author
  • Контрибьютор, который заливает патчи через своего спонсора
  • Аккаунт в JBS

Коммитер

  • Committer
  • Автор, который может заливать патчи сам (push access)
  • "8 важных изменений"

Ревьюер

  • Reviewer
  • Опытный коммитер, который может подтверждать ченжсеты
  • "32 важных изменения"

Лид проекта

  • Project Lead
  • Коммитер, который отвечает за управление и координацию всего проекта

Проекты JDK и JDK Updates

  • Проект JDK — это мейнлайн разработка jdk-dev с соответствующими репозиториями в openjdk/jdk (всегда доступен для разработки)

  • Проект JDK Updates — проект под предводительством Rob Mckenna, openjdk/jdk{$N}u, создается во время RDP2 (Rampdown Phase 2, code freeze), обновляется на протяжении 6 месяцев, и потом отдается в сообщество

Релиз JDK 21

  • Описание
  • Набор фичей из JEP
  • График фаз разработки

Релиз JDK 21

  • Описание
  • Набор фичей из JEP
  • График фаз разработки

График выпуска JDK 21

Фазы замедления

JEP 3: JDK Release Process

Все немного сложнее

https://cr.openjdk.org/~mr/jep/jep-2.0-02.html

  • Panama
  • Valhalla
  • Loom
  • Amber
  • Leyden
  • ZGC

Panama

Обновление и улучшение связи между виртуальной машиной и хорошо описанным, но "внешним" API (не Java)

C/C++

struct Slot {
  uint32_t offset;
  uint32_t length;
}

void write_to_buffer(char *buffer, Slot& slot, uint32_t slot_idx) {
    memcpy(buffer + sizeof(Slot) * slot_idx, &slot.offset, sizeof(uint32_t));
    memcpy(buffer + sizeof(Slot) * slot_idx + sizeof(uint32_t), &slot.length, sizeof(uint32_t));
}

void read_from_buffer(char *buffer, Slot& slot, uint32_t slot_idx) {
    memcpy(&slot.offset, buffer + sizeof(Slot) * slot_idx, sizeof(uint32_t));
    memcpy(&slot.length, buffer + sizeof(Slot) * slot_idx + sizeof(Slot), sizeof(uint32_t));
}

Старая школа: ByteBuffer

  record Slot(int offset, int length) {
      void write(ByteBuffer buffer) {
          buffer.putInt(offset).putInt(length);
      }

      static Slot read(ByteBuffer buffer) {
          return new Slot(buffer.getInt(), buffer.getInt());
      }
  }
record Slot(int offset, int length) {
    public static MemoryLayout LAYOUT = MemoryLayout.structLayout(
            ValueLayout.JAVA_INT.withName("offset"),
            ValueLayout.JAVA_INT.withName("length"));

    public static Slot from(MemorySegment memory) {
        return new Slot(
                memory.get(ValueLayout.JAVA_INT, 0),
                memory.get(ValueLayout.JAVA_INT, Integer.BYTES));
    }

    public void to(MemorySegment memory) {
        memory.set(ValueLayout.JAVA_INT, 0, offset);
        memory.set(ValueLayout.JAVA_INT, Integer.BYTES, length);
    }
}

FFM:
JEP 442

Valhalla

Повышение плотности данных и улучшение производительности для Big Data и машинного обучения.

Достигается с помощью инлайн-классов.

Старая школа

Полностью последовательное вычисление

void scalarComputation(float[] a, float[] b, float[] c) {
   for (int i = 0; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
   }
}
static final VectorSpecies<Float> SPECIES =
                           FloatVector.SPECIES_PREFERRED;

void vectorComputation(float[] a, float[] b, float[] c) {
    int i = 0;
    int upperBound = SPECIES.loopBound(a.length);
    for (; i < upperBound; i += SPECIES.length()) {
        // FloatVector va, vb, vc;
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        var vc = va.mul(va)
                   .add(vb.mul(vb))
                   .neg();
        vc.intoArray(c, i);
    }
    for (; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
    }
}

JEP 448:
Vector API

Vector API: Assembly + AVX

0.43%  / │  0x0000000113d43890: vmovdqu 0x10(%r8,%rbx,4),%ymm0
  7.38%  │ │  0x0000000113d43897: vmovdqu 0x10(%r10,%rbx,4),%ymm1
  8.70%  │ │  0x0000000113d4389e: vmulps %ymm0,%ymm0,%ymm0
  5.60%  │ │  0x0000000113d438a2: vmulps %ymm1,%ymm1,%ymm1
 13.16%  │ │  0x0000000113d438a6: vaddps %ymm0,%ymm1,%ymm0
 21.86%  │ │  0x0000000113d438aa: vxorps -0x7ad76b2(%rip),%ymm0,%ymm0
  7.66%  │ │  0x0000000113d438b2: vmovdqu %ymm0,0x10(%r9,%rbx,4)
 26.20%  │ │  0x0000000113d438b9: add    $0x8,%ebx
  6.44%  │ │  0x0000000113d438bc: cmp    %r11d,%ebx
         \ │  0x0000000113d438bf: jl     0x0000000113d43890

Loom

Легковесные треды, масштабирующиеся в количестве до миллионов.

Многопоточность снова легко писать.

Thread.Builder

try {
    Thread.Builder builder = Thread.ofVirtual().name("MyThread");
    Runnable task = () -> {
        System.out.println("Running thread");
    };
    Thread t = builder.start(task);
    System.out.println("Thread t name: " + t.getName());
    t.join();
} catch (InterruptedException e) {
    e.printStackTrace();
}

newVirtualThreadPerTaskExecutor

try (ExecutorService myExecutor =
    Executors.newVirtualThreadPerTaskExecutor()) {
    Future<?> future =
        myExecutor.submit(() -> System.out.println("Running thread"));
    future.get();
    System.out.println("Task completed");
} catch (InterruptedException | ExecutionException e) {
    e.printStackTrace();
}

Frameworks

  • Spring Boot
  • Helidon WebServer (бывш. Helidon Nima)
    • Создан специально для виртуальных потоков
  • Micronaut (автоопределение)
  • Quarkus @RunOnVirtualThread

Spring Boot

@Bean(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME)
public AsyncTaskExecutor asyncTaskExecutor() {
  return new TaskExecutorAdapter(Executors.newVirtualThreadPerTaskExecutor());
}
@Bean
public TomcatProtocolHandlerCustomizer<?>
protocolHandlerVirtualThreadExecutorCustomizer() {
  return protocolHandler -> {
    protocolHandler.setExecutor(

      Executors.newVirtualThreadPerTaskExecutor()

    );
  };
}

Helidon

  • Митя Александров
  • Helidon 4 специально создан для Virtual Threads

Amber

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

Непрерывная эволюция языка Java.

Java 8

Поля

private static class Point {
    private int x;
    private int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

Сеттеры

public int getX() {
    return x;
}

public void setX(int x) {
    this.x = x;
}

public int getY() {
    return y;
}

public void setY(int y) {
    this.y = y;
}

Применение

Object obj = new Point(1, 2);

if (obj instanceof Point p) {
    int x = p.getX();
    int y = p.getY();
    System.out.println(x+y);
}
public static void main( String[] args )
{
    record Point(int x, int y) {}

    Object obj = new Point(1, 2);

    if (obj instanceof Point p) {
        int x = p.x();
        int y = p.y();
        System.out.println(x+y);
    }
}

Java 16

  public static void main( String[] args )
  {
      record Point(int x, int y) {}

      Object obj = new Point(1, 2);

      if (obj instanceof Point(int x, int y)) {
          System.out.println(x+y);
      }
  }

Java 21

Leyden

Ускоряение запуска Java-приложений, время до выхода на максимальный перформанс, и объем занимаемой памяти.

"Java тормозит"? Больше не тормозит.

ZGC

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

Терабайт памяти — не сказка, а практика.

  • Panama
  • Valhalla
  • Loom
  • Amber
  • Leyden
  • ZGC

Quality Outreach Program

  • Появилась как реакция на баг в JDK
    • Баг в оптимизаторе Java 7
    • Краш JVM на Lucene и Solr
    • Баг нашли всего за 5 дней до публикации релиза JDK

http://www.h-online.com/open/news/item/Java-7-paralyses-Lucene-and-Solr-1288210.html

Quality Outreach Program

Что нужно, чтобы поучаствовать?

Нужно написать заявку в мейлинг-лист quality-discuss

  • Имя проекта
  • Контакты участника, который будет отвечать за проект
  • Actively Tested on: версия вашего JDK
  • Какие фичи используете, какие проверяете на свежей Java

Quality Outreach Program

Какие плюшки от участия?

  • Участие в тематическом сообществе мантейнеров
  • Повышенное внимание от разработчиков JDK
  • Оповещения о важных изменениях от разработчиков JDK
  • Роль автора в JBS
  • Возможность вместе продвигать идею
    перехода на самые свежие версии Java

Как стать контрибьютором?

Oracle Contributor Agreement (OCA)

  • Заполнить форму: https://oca.opensource.oracle.com
  • Работает со всеми Open Source проектами Oracle

  • Регистрация на выбор: частное лицо или сотрудник компании
  • Организации могут подписывать его за своих сотрудников
  • Обязательно обсудите с работодателем, если он заполняет за вас

  • Не вздумайте регистрироваться как российская компания!

Как стать контрибьютором?

OpenJDK Developers Guide

  • https://openjdk.org/guide
  • Отличное место, чтобы начать свое путешествие
  • Отвечает на стандартные вопросы про процесс разработки, инструменты, стандарты, и так далее.

Получить исходный код

  • git clone https://github.com/openjdk/jdk.git
  • Сделать форк репозитория на GitHub
  • Настроить проект:
    • git remote rename origin upstream
    • git remote add origin https://github.com/olegchir/jdk.git
    • git checkout -b 2023-11-27-highload-fix

Cобрать OpenJDK

configure

  • Нужна предыдущая версия JDK
  • Нужен нативный тулчейн
    (GCC/Linux, Visual Studio/Windows, XCode/Mac)
  • Требует дополнительных пакетов (в зависимости от ОС)

make images

  • Собирает "релизный имидж"

Прогнать тесты JTreg

  • Чтение тестов способствует пониманию.

  • Стандартная регрессионная тестовая сюита

sh ./configure --with-jtreg=/path/to/jtreg
make test TEST=path/to/MyTest.java

jtreg -jdk:/path/to/jdk /path/to/test

Открыть в IDE

  • NetBeans — встроенная поддержка
  • VSCode — сторонние плагины
  • IntelliJ — есть плагин для JTReg

Чем можно помочь?

  • Писать коды
  • Помогать можно не только кодом!
  • Рассказывать о любых проблемах проблемы
    • Включая опечатки в документации
    • Включая разницу между ожидаемым и реальным в тестах
  • Вместо тестов можно писать программы-примеры с ошибкой

Про что рассказывать?

Что рассказать

  • Что сработало, и что — нет?
  • Как новые фичи повлияли на вас?
    • Конечные прикладные приложения
    • Фреймворки и технологии
  • Что случилось с производительностью?
  • Пришлось ли переписывать код?

Как донести свой фидбек?

Стандартные каналы связи

  • Почта, Twitter и другие соцсети, Reddit, Hackernews

Создавать контент

  • Статьи и посты в интернете
  • Доклады на конференциях
    • Сделать свой доклад
    • Подойти с вопросами на чужой

Хабр

  • Лучшее место для общения на русском языке h/java
  • Нужен инвайт?
  • Нужно помощь в написании статьи?
    • Ревью и вычитка статьи
    • Проверка по смыслу

Поддержка всех LTS версий Java

+ Промежуточные версии поддерживаются 6 месяцев

Axiom JDK Certified

  • Сертифицирован по 4УД, в соответствии с требованиями ФСТЭК России
  • Реализована концепция процесса безопасной разработки ПО (SDL)
  • Объем верифицированного исходного кода российского дистрибутива среды исполнения Java составляет 12 млн строк
  • Доработан сборщик мусора: сделали работу более детерминированной

Контакты 📧

Официальные

AxiomJDK

Личные

Олег Чирухин

На слайдах будет много ссылок Вы **не** успеете их сфотографировать Вот единственная ссылка, которая вам нужна Слайды сверстаны в HTML и ищутся в гугле Так что, слайды останутся с вами

- 10 лет джавы. - Деврел Axiom JDK ---

Привет, меня зовут Олег Чирухин, последние десять лет я занимаюсь Джавой. Сейчас я деврел в команде дистриубтива Java под названием Axiom JDK

- Российский дистрибутив - КИИ, ФСТЭК ---

AxiomJDK - это такой российский дистрибутив Java, который внесен в Реестр российского ПО и сертифицирован по ФСТЭК, поэтому мне кажется, что именно мне имеет смысл рассказывать о фичах новой Java

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

Обязательный юридический слайд Идея позаимствована у Леши Шипилёва Он это придумал в те времена, когда работал в Оракле Почитать, что такое Safe Harbor можно на Википедии Если вкратце, никому не верьте, даже мне, думайте своим мозгом.

Каждый год, дважды в год, выходит новая версия Java. Новые фичи языка, виртуальной машины, стандартных библиотек. Большинство из того, что вы сегодня услышали, стало возможно благодаря проекту Open JDK. То, что мы можем использовать этот код на практике - заслуга дистрибутивов, которые собирают его в работающий продукт: например, это Oracle JDK или Axiom JDK. В этом докладе хочется поговорить о том, как происходит вся эта магия, и возможно, как в ней поучаствовать. Это доклад в первую очередь для энтузиастов Java и для новичков, которые хотят когда-нибудь в будущем стать JVM-инженерами.

Что будет в этом докладе. Вначале хочется рассказать, почему эта тема вообще важна. В этом зале есть люди, которые пришли сюда специально, а есть те, кто просто заинтересовался названием, и это для них. Дальше я расскажу, что такое OpenJDK. Потому что всё еще есть недопонимание. И люди называют словом "OpenJDK" вполне конкретные бинарные сборки. И конкретная сборка сама по себе OpenJDK не явлется. Мы посморим, как организована разработка, какой жизненный путь складывается у коммитера, какие подпроекты есть в OpenJDK, и на какие ресурсы стоит обратить внимание. Если останется время, то на примере одного коммита покажу, как происходит участие в проекте. Если времени не останется, мы посмотрим на этот пример в кулуарах. Ну и наконец, буквально на полторы минуты я расскажу, как происходит разработка Java в России. Axiom JDK не входит в компании JCP по причинам, связанными с событиями прошлого года. У нас есть своя кодовая база. Она тоже использует опенсорс как основу. И там происходят свои интересные вещи, например, кастомная доработка сборщиков мусора.

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

Кроме того, это один из самых любимых языков. Джаву обгоняет только Python. Скорей всего, потому, что на Python сейчас пишут нейросети, а нейросети - на хайпе. Работа над реализаций машинного обучения на Java ведется, но это всё еще не настолько удобно как в Питоне.

Как сказал сооснователь компании RedMonk: Java показала невероятную способность адаптироваться к быстро изменяющемуся ландшафту технологий. RedMonk - это специальная контора, которая собирает аналитику по использованию инструментов для разработчиков. Она ведет свой рейтинг языков и продает все эти данные за деньги. На слайде некоторые инсайты, которые добыла эта компания. - 60 миллиардов активных JVM - 34 миллиарда JVM в облаке - 98% компанияй из Fortune 100 нанимают джавистов Джава реально повсюду.

Как вы, наверное, знаете, только что вышла 21 Джава. С огромным количеством измненений в Рантайме. В том числе виртуальные потоки, которые мы ждали в течение 20 лет, с тех пор как в первых версиях Джавы убрали зеленые трдеды.

Изменения в языке тоже есть. Не настолько большие как виртуальные треды, но все же. Все это вызывает огромное чувство гордости. Может быть, потому, что я работаю в компании, которая делает дистриубтив JDK. Но хочется верить, что каждый джавист, который сейчас сидит в зале, он тоже испытывает по этому поводу что-то хорошее. !!!Тут можно попросить подять руки, сколько джавистов сейчас в зале. ///Кстати, давайте посмотрим, сколько джавистов сейчас в этом зале. Поднимите руку, если пишете на Java!/// ... статистика подтвердается, примерно половина из нас использует Java.

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

В России, например, на нашем дистрибутиве AxiomJDK работает Система Быстрых Платежей. А это значит, что каждый третий житель России, каждый день, косвенно использует Java. Даже если он не разработчик и никак не связан с высокими технологиями.

Последнее время релизы выходят как часы, дважды в год. Сейчас выходит 12-й релиз, выпущенный по этой новой схеме. Скоро мы перестанем помещаться на этот слайд, когда выйдет Java 22. Но общая идея ясна: выпуск релизов крайне стабильный, крайне консистентный. Всегда вовремя, в марте и сентябре. Такой темп выпуска релизов позволяет попробовать новые фичи быстрее. Раньше релизы выпускались с промежутком в 3-4 года. Это было очень долго. И создавало иллюзию того, что в джаве всё продвигается медленно и ничего нового нет. Хотя на самом деле новое всегда было, просто его всегда выпускали в полностью готовом виде. Сейчас мы можем посмотреть на новые фичи прямо в процессе их создания. Чтобы все это стало возможным, делается огромная работа.

Как на новый имидж Джавы реагирует общественность О джаве регулярно пишутся новые статьи. В том числе на русском языке, на Хабре. На английском языке это Реддит, Хакерньюс, Твиттер, Линкедин. И отзывы в целом очень положительные.

Всё это стало возможным благодаря проекту OpenJDK. И благодаря компаниям, которые собирают из него дистрибутивы. Вы тоже можете поучаствовать в этой разработке. Когда-то Джаву начинал делать Оракл, и он был единственной компанией, которая что-то могла. Но больше это не так. Где-то половину работы делают контрибьюторы, которые не работают в Оракле, которые работают в других местах. Есть даже индивидуальные контрибьюторы, которые не зарегистрированы ни от какой компании И тем не менее, они могут делать свой вклад в OpenJDK. Это довольно важный момент, потому что российские компании сейчас не могут коммитить в OpenJDK. Такие контрибьюшены не примут, потому что мы из России. Но тем не менее, работу индивидуального контрибьютора вполне могут принять. Кроме того, никто не запрещает вам работать над своим форком OpenJDK, в чисто исследовательских целях, и решать свои собственные исследования. А если вы серьезно настроены и хотите стать JVM-инженером, то в России есть российский дистрибутив Java, который называется Axiom JDK. Вы можете устроиться туда на работу, и работать фуллтайм за деньги. AxiomJDK сейчас временно не коммитит в OpenJDK, но у него есть своя кодовая база, которая помогает писать софт для примнения внутрии России.

Что такое OpenJDK? OpenJDK - это место, где разрабатывается опенсорсная основа для дистрибутивов Java. Кто-то говорят, что OpenJDK - это "такая штука", это дистрибутив, это комьюнити, это проект... На самом деле, это место. Виртуальное место. В котором люди собираются, чтобы вместе работать над этими вещами. Если ты спрашиваешь кого-то, каким дистрибутивом Джавы он пользуется. А вам отвечают, что они установили на компьютер OpenJDK, то это не очень правильный способ излагать мысли. На компьютер можно установить какой-то дистрибутив джавы, например Oracle JDK или Axiom JDK. Но на компьютер нельзя установить МЕСТО. Правильным выражением было бы, например, я склонировал репозиторий OpenJDK с гитхаба, собрал и запустил его. Это более корректное выражение. Которое справедливо для тех, кто участвует в разработке джавы. Кстати, заметьте, что сайт называется OpenJDK.org. Раньше он назывался openjdk.java.net, что как бы подчеркивало его связь с компанией Oracle. Но теперь джаву разрабатывает не только Оракл, и отдельный сайт имеет большое символическое значение.

В OpenJDK поддерживается несколько основных ресурсов, с помощью которых разработчики вместе работают над проектом. Как видите на слайде, это групы, проекты, списки расслок, вики. И JEP-ы, JDK Enchancement Proposal, это руководящие документы. Несмотря на то, что разработчиков много, общая цель в том, чтобы сформировать общее видение проета и сделать так, чтобы все новые фичи вливались в джаву бесшовно. Чтобы в любой момнет казалось, что все эти возможности всегда у нас были. И если какая-то фича все-таки была реализована и попала в JDK, то она останется с нами на долгие годы, возможно - навсегда. Она должна быть реализована правильно, и ощущаться как самая настоящая Джава. Фичи не должны ощущаться как будто бы они были созданы как реакция на какие-то тренды, на моду, на другие языки. Не должно быть так, чтобы фича была прикручена сборку на синюю изоленту. Пройдет несколько лет и вся текущая мода перестнет быть модной. Не должно быть так, чтобы фичи начинали торчать в разные стороны как инородные отростки. К сожалению, так часто происходит в экосистеме JavaScript. В JS фреймворки очень сильно управляются модой, и если ты сегодня написал проект на новомодном Next.js версии 12, может оказать так, что после выхода Next.js 13 либо тебе как прикладному разработчику придется переписать свой проект на нуля. И если бы разработчики самого Next так же заботились о легаси, как джависты, им пришлось бы тащить легаси фичи, которыми больше никто не пользуется, всю историю существования фреймворка. Даже Java в это наступила. Потому что, например, у нас есть фреймворк Swing, и Swing обязан быть реализован везде, даже там, где он не нужен. Например, на Анроиде. У Андроида своя графическая бибилиотека, Свингом там никто не пользуется, но реализовывать его обязаны. В джаве такого быть не должно. По крайней мере, сама базовая платформа должна быть консистента и расчитана на долгое будущее. Поэтому разрабатывать нужно крайне аккуратно. Многие спрашивают, почему мы двигаемся так медленно. Это не медленно, это разумно и аккуратно. Аккуратно смотрим, что работает, и что нет. Очевидно, что такой подход приводит к очень высокому порогу входа в участие в проекте. Никто не может прийти и сказать: глядите, у меня тут появилась новая крутая идея, давайте вольем ее в OpenJDK, поехали! Тем не менее, участие в проекте обычно очень ценится.

Основная структурная единица OpenJDK - это группы. Это группы людей, которые вместе интересуются общими проблемами Например, группа по компиляторам заинтересована в развитии компиляторов

Группы поддерживают проекты. Каждый проект призван создать вполне конкретный артефакт. Проекты состоят из расслок, вики, репозиториев, и так далее.

Например, новые виртуальные треды из Java 21 сделаны в рамках проекта Loom.

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

Теперь, можно зайти на страничку этой группы и посмотреть, кто эти люди И какие проекты они поддерживают То есть, это не какие-то ноунеймы, это извесные люди, которые отвечают за свои действия

Я не буду много рассказывать о высшем управлении проектом. Просто потому, что оно обычно не касается простых людей. Существует совет OpenJDK Есть два президента, они назначаются компаниями Oracle и IBM. Есть глава самого OpenJDK Есть 2 выборных участника. Это два самых важных и любимых разработчика, которых демократически выбирает всё сообщество. Все эти ребята занимаются управлением по кодексу, сслка на кодекс есть по ссылке на слайде. Правление не вмешивается в непосредственную работу разработчиков. Не вмешиваются в конкретную работу по проектам, не влияет на технический результат. Они занимаются тем, чтобы поддерживать здоровое сообщество, руководствуясь своим сводом правил.

Почтовые рассылки. Как общаются люди внутри проектов? В OpenJDK всё ещё используются почтовые рассылки. На экране сейчас скриншот типичного мейлинг-листа. Это проект Loom, в котором делаются виртуальные треды. Нужно понять, что вся работа, которая делается в Java обсуждается и происходит здесь. В рассылке. Если кто-то привыкли пользоваться Дискордом, Реддитом и Телеграмом. Они могут подумать, что это шутка. Это не шутка. Это реальность. Есть попытки перейти на использование современных средств типа GitHub. Но сейчас дискуссии на Гитхабе отключены. Потому что на практике, рассылки оказываются удобнее, чем комменты на гитхабе. Особенно, когда речь идет о долгих, разветвленных дискуссиях, которые могут длиться годами. Представим, что у тебя есть крутая идея. Ты написал кусок кода, который ее реализует. Ты не можешь просто так залить этот код на Гитхаб в пул-риквест, и закричать "эхей, давайте замерджим прямо сейчас!". Вначале предстоит долгая работа по обсуждению этой фичи вот в таких списках рассылки. И она может занять литералли годы, в зависимости от того, что это за фича, и какой импакт она имеет на проект.

Иногда ты заходишь на сабреддит Java, и там кто-нибудь кричит ЭЭЭЭЭЭЭЙ ПОЧЕМУ ВЫ В ДЖАВЕ НЕ ДЕЛАЕТЕ ВОТ ТАКОЕ! Почему вы не переделаете в Java работу с null? Чтобы было как в Котлине! А ему в комментариях отвечают: а зачем? А он такой: не зачем, а как в котлине! Ну и продолжает в комментариях спрашивать, почему.

Ну вот потому. Потому что на самом деле, всё это обсуждается. Просто не Реддите. Вот достаточно свежий тред 2022 года. И там постоянно такое происходит. Надо знать, где смотреть.

Самое интересное, что автор конкретно вот этого сообщения, он прежде чем писать в рассылку, всё-таки обсудил этот вопрос на Реддите

Вот этот пост, он собрал достаточно много плюсов. Он хорошо оформлен и его приятно почитать. У него пара десятков комментариев. Но тем не менее, нужно понимать, что Реддит - это не источник истины. В конце концов всё должно попасть в почтовую рассылку, и вот только тогда коллеги тебя услышат.

Тем не менее, новые технологии внедряются. Например, достаточно недавно репозиторий OpenJDK был перенесен на GitHub И теперь можно посмотреть красивую статистику с красивыми графиками, что там происходит.

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

Причем, если посмотреть на профиль типичного разработчика в OpenJDK, то вы увидите вот такую картину. Почти все клеточки на его календаре - зеленые. Это значит, что он коммитит почти каждый день. Для людей, которые пытаются писать опенсорс в свободное время, это может показаться очень демотивирующей картинкой. Потому что у тебя эта клеточка может быть всего одна в неделю. Или всего одна в месяц. Но тут надо понимать, что для тебя это хобби, и ты пишешь в свободное время. А для этого чувака со слайда - это основная работа. Он больше ничего в жизни не делает, только коммитит в джаву. И поэтому когда вам рассказывают разные истории, о том, что опенсорс пишется свободными людьми исключительно по собственной иницитиве. Помните вот эту картинку. Все-таки, большинство опенсорса пишется силами сотрудников огромных корпораций. То, что у Джо Дарси, главного разработчика Оракла, весь Гитхаб зеленый, не должно тебя никаким образом демотивировать. Потому, что просто сравнивать себя с Джо Дарси не нужно. Вы в радикально разных позициях. Ты не плохой разработчик. Просто у тебя пока нет лишних нескольких десятков миллионов рублей в год, чтобы ничего не делать, а только коммитить в опенсорс. Как только появятся - ты сможешь так же.

Тепепрь, поговорим о ролях. Роли дают тебе определенные права в сообществе. Обычный путь в том, чтобы пройти от автора до коммитера, до ревьюера. Чтобы когда-нибудь в будущем, может быть, стать главой проекта. Каждую следующую роль получить всё сложнее и сложнее. Ты должен постоянно быть на виду, делать работу, повышать свою репутацию, показывать, что ты можешь делать много полезных вещей. И эти вещи будут принимать и подтверждать коллеги, и они будут полезны проекту в целом.

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

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

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

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

В openjdk есть куча разных подпроектов, все со своими репозиториями. Проект JDK - это самый большой проект вообще. Именно его я показывал на скриншотах выше. Это мейнлайн, это самый свежий свежак на свете. Это то, где происходит вся разработка. Дальше в какой-то момент случается фаза разработки под названием Rampdown Phase 2, код замораживается и отправляется в проект JDK Updates и дальше маринуется там на протяжении полугода. Как работает этот проект Updates, наверное, немного выходит за рамки этого разговора. Тем не менее, идея такова.

Посмотрим работу этого механизма на примере Java 21, которая только что вышла. Java 21 - это чуть ли не самая важная версия Java начиная с 11, потому что там появились виртуальные треды. То есть, это первая версия Java за всё это время, на которую прямо стоит обновиться. Стоит-стоит. Каждый релиз джавы описывается документом, в котором описаны ключевые особенности этого релиза. Наличие таких документов позволяет разработчикам синхронизироваться и понимать, что вообще происходит. Если бы таких управляющих документов не было бы, в проекте происходил бы разброд и шатание. К счастью, они есть. В таком документе всегда есть список фичей, которые вошли в состав релиза.

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

Фазы замедления (две rampdown phase) заканчиваются двумя релиз-кандидатами, и наконец - полноценным релизом (который у нас называется general availability). В целом, что здесь происходит. Со временем становится всё сложнее и сложнее добавить что-то в релиз. Тебе нужно заморозить кодовую базу до того, как она попадет в руки конечным пользователям. Значит разработчикам нужно как-то запрещать коммитить свежие изменения. Тут может возникнуть вопрос, чем отличается первая фаза от второй фазы. Или первый релиз-кандидат от второго. Это просто наше какое-то внутренее ощущение "готовосности" или что-то большее?

На это есть очень хороший ответ. Он описан в руководящем документе под названием JEP 3: JDK Release Process Всем задачам и багам в JDK выставляется приоритет. От P1 до P5. Баги вида P1 - это "всё бросаем, надо чинить". Баги P5 - это то, о чем можно не беспокоиться. Кстати, эту фишку с приоритетами я взял в свою личную жизнь, не в разработку. Когда я знакомлюсь с человеком, я выставляю ему приоритет с 1 по 5, и дальше общаюсь с ним по точно тем же правилам, что и в JDK работают с багами. Очень хорошая система, всем рекомендую. Например, если тебе приходит сосед по площадке ругаться, и у него приоритет P5, то можешь даже не открывать дверь. А если тебе звонит выносить мозг девушка, и у нее приоритет P3, то тут можно подумать. Возвращаясь к JDK. Фазы замедления отличаются между собой теми багами, на которые можно закрыть глаза. В ходе первой фазы замедления еще можно экспериментировать. На этой фазе считается нормальным иметь недоделанные задачи вплоть до приоритета 3, но их нужно поправить. На второй фазе замедления можно править только задачи высших приоритетов. И фиксы в них можно заливать только то после аппрува лидами проектов или функциональных областей. Во время релиз-кандидата можно править только P1. Ну, а второго релиз-кандидата и собственно релиза в этой таблице нет. Потому что на этих этапах код уже полностью зафиксирован. Конечно, тут может возникнуть вопрос, а что делать, если что-то пошло не по плану. Ну, пока что все идет по плану. Схема работает. И эта схема позволяет выпускать джаву два раза в год. Конечно, чтобы она лучше работала есть разные приемы, я дальше расскажу про Quality Outreach Program, это оно.

На самом деле, все немного сложнее, но об этом лучше почитать самостоятельно. Если я буду рассказывать каждый этап бизнес-процесса, то вам придется слушать этот доклад до вечера. Что, наверное, не входит в наши с вами планы. Весь процесс описан в документе JEP-2, и это хороший, умный документ. Если вы строите свой опенсорс-проект и уже задумываетесь, как там организовать процессы. То вот вам хороший шаблон, с которого можно всё слизать. Его польза в том, что этот шаблон прошел проверку временем, двадцатью годами разработки Джавы. И никто не прячет его как коммерческую тайну. Бери и пользуйся. И все у тебя будет хорошо.

В OpenJDK есть несколько проектов, цель которых - раздвигать границы возможного. Приближать будущее, реализуя новые крутые фичи. На слайде перечислено несколько таких проектов. Это не все проекты, а только часть, самые активные и популярные. Давайте пройдемся по ним.

Проект Панама занимается тем, что учит Джаву работать со внешним по отношению к виртуальной машине кодом. Например, написанным на C++. И занимается всеми связанными вопросами типа управления памятью.

Представьте, что вы пишите базу данных, и хотите написать ее целиком на Java. Вначале это может показаться безумной идеей. И такой она казалсь в самом начале, когда Java только появилась. А теперь вспомните, сколько сейчас таких баз развелось - Cassandra, Apache Ignite/GridGain, Kafka в конце концов Представим, что в нативном коде нам нужно напрямую работать с каким-то куском памяти. В Си или C++ это выглядело бы как-то так. Это скорее псевдокод, а не точный код, потому что мы много чего не учитываем типа размера оффсетов и хидеров. Но это неважно, идею он дает. В C++, у нас была бы структурка в памяти, которую ты сохраняешь с помощью memcpy. В джаве, исходно, такого удобного API нет. Потому что предполагалось, что Java как раз должна охранять разработчика от необходимости вот таким заниматься.

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

Начиная с 21 джавы мы можем использовать новое Memory API Вроде бы, кода в количестве букв больше. Использование классов типа MemorySegment дает куда больше контроля за описанием лэйаута (раскладки в памяти), и управления им (освобождение и пулинг). Больше контроля, чем это дает ByteBuffer. Кроме того, ты больше не упираешься в ограничения ByteBuffer по размеру. Производительность при этом как минимум не хуже, а иногда и лучше, чем у ByteBuffer. Дело в том, что ByteBuffer делали во времена Java 1.4 в рамках NIO, и он должен был удовлетворять ограничениям платформы, особенностям ее внутреннего устройства, которые больше в 2023 не являются проблемой. Но переписать ByteBuffer нельзя, потому что от этого у всех всё сломается, поэтому у нас есть новое, более лучшее API.

Вальгалла. Сейчас на Java пишут большие данные, это Спарк и Хадуп. А вот машинное обучение почти не пишут. Вся эта область почему-то досталась Питону. Так исторически сложилось. Плюс, у Джавы есть очевидные проблемы с эффективностью использования оперативной памяти. Поэтому, если вы там захотите сделать свой собственный класс Integer и на нем напишете числодробилку А все машинное обучение - это числодробилки. То ваш алгоритм будет тратить память как не в себя и очень сильно тормозить. Конечно, можно сделать как в Пайтоне - написать всё на C++, и использовать высокоуровневый язык просто как клей. Но джавистам такая идея почему-то очень не нравится. Она очень ограничивает. Эта проблема издавна беспокоила джавистов, и ее решению посвящен проект Вальгалла.

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

Новое Vector API повышает производительность кода, который можно написать так, чтобы использовать векторные инструкции процессора во время выполнения приложения. Фича появилась в JDK 16, и с тех пор очень много воды утекло. В 21 джаве, это уже шестой incubator, шестой промежуточный выпуск. Вот так это вычисление будет выглядеть на Vector API. Кажется, как будто бы здесь написано больше кода. Но зато, этот код лучше понимается компилятором.

И благодаря этому, JIT-компилятор C2, может сгенерировать вот такой оптимальный код на процессорах 64-битных процессорах Intel с поддержкой инструкций AVX.

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

Конечно, всегда можно перейти на написание асинхронного кода. И прекратить нашу красивую Java в некое подобие Node.js. Но при этом без всяких плюшек Node.js Ни один человек в своем уме на такое не подпишется. Точнее, раньше так приходилось делать от безысходности, но больше не нужно.

Лум это супер древний проект. Его начал более 10 лет назад вот этот улыбающийся молодой человек со слайда. Его зовут Рон Пресслер. Когда-то он начинал как независимый разработчик. Сейчас отвечает за проект Лум в компании Оракл. Что показывает, что возможность социального лифта до главы проекта достаточно велика

Виртуальные треды появились в 21-й джаве в рамках JEP 444. Их уже можно использовать в проде. Вот пример, как можно самому сделать виртуальный тред. Нужно позвать метод Thread.ofVirtual(). Так у вас появится Thread.Builder, и вот этот билдер уже может делать виртуальные треды.

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

Но кроме этого, виртуальные треды сейчас начали поддерживать все популярные веб-фреймворки Спринг, Хелидон, Микронавт, Кваркус

В Spring Boot их поддержка включается буквально одной строчкой в конфигурации. Ты создаешь бин, в котором переопределяешь системный экзекьютор тредов.

Кроме того, наш большой друг Митя Александров, который является одним из команды фреймворка Helidon в Oracle, сделал собственные тесты. Helidon в самой его свежей версии использует новый движок под названием Нима, который с нуля создан для использования с виртуальными тредами. И только с ними, без них, на старых джавах, он просто не запустится.

И вот по тестам Мити, сам Хелидон при переходе на виртуальные треды разогнался примерно в 3 раза начал обрабатывать в 3 раза больше запросов

А встроенный в него веб-сервер, в минимальной конфигурации, обогнал Нетти в 10 раз. Нетти - это самый популярный сейчас в Java-мире веб-сервер, который используется во всех фреймворках И согласитесь, это очень крутой эффект от фичи, в которой вам даже не нужно разбираться. Просто обновляетесь на 21 джаву, и все само работает.

Проект Amber - это куча мелких разрозненных улучшений. У них как бы нет никакой своей общей идеи кроме того, что они повышают User Experience для разработчика. Обычно это какие-то мелкие плюшки в синтаксисе языка

Например, раньше в Java всех бесили бесконечные геттеры и сеттеры, которые ты должен был генерировать через IDE. Представьте, что вы сделали класс Точка и хотите достучаться до его полей. В восьмой джаве вам нужно было писать вот такое уродство.

В 16 джаве появились рекорды, стало возможным не писать геттеры-сеттеры, но всё равно приходится вручную доставать поля. Здесь мы можем или забыть поле, или опечататься, или еще что-нибудь. И IDE никак не поможет.

В 21 джаве мы получаем поля в одну строчку. Очень удобно. И все такие изменения обычно происходят в проекте Amber

Другая проблема джавы в том, что она очень долго запускается и требует прогрева виртуальной машины. Что очень неприятно, особенно в облаках, когда за этот самый прогрев вам нужно платить деньги. Существует проект GraalVM Native Image, который компилирует джаву в исполняемые файлы. Например, это exe-файлы на Винде. Такие файлы быстро запускаются и мало весят в оперативной памяти. Но у Грааля есть несколько проблем. Во-первых, он компилирует очень долго, даже хэлло ворлд компилируется целые минуты. Во-вторых, Грааль хоть и построен на основе OpenJDK, он по сути - совершенно другой продукт. Со своей спецификой, со своими проблемами, со своей кодовой базой, и так далее. Поэтому существует проект Leyden, который посвящен тому, чтобы сделать что-то подобное в рамках основного проекта OpenJDK. Это достаточно молодая инициатива, и пока что показать особо нечего.

Ну и наконец ZGC. Это сборщик мусора, который призван работать хорошо в общем случае. И не останавливаться на Stop The World, даже если приложение обрабатывает терабайты памяти. Это опять же очень важно для больших данных и машинного обучения. ZGC уже существует, уже работает, им уже можно пользоваться на проде. И с каждым релизом он становится лучше. Например, в 21 первой джаве его научили работать с поколениями объектов. Тем самым он стал тратить меньше ресурсов.

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

Как во всем этом можно поучаствовать. Во-первых, есть Quality Outreach Program Эта программа появилась во времена седьмой джавы. Когда за 5 дней до релиза выяснилось, что использование Lucene и Solr роняет JVM И это не проблема самого Lucene, это баг в оптимизаторе джавы

Идея этой программы в том, что у каждой большой библиотеки есть мантейнеры этой библиотеки, которые добровольно взяли на себя ответственность проверять новые версии своего кода относительно свежих версий джавы. А разработчики OpenJDK помогают им с этим тестированием всем, чем нужно. Кстати, по этой табличке можно увидеть, что свежий Hadoop не запускается на 21-й джаве. Никогда такого не было, и вот опять. И ты даже знаешь, кому писать, если что - писать нужно Акире

Чтобы поучаствовать в программе, нужно банально заполнить заявку и отправить на почту

Чтобы стать контрибьютором и иметь возможность заливать код в репозиторий, Нужно будет подписать юридическую бумажку, что ты согласен делиться результатами своего труда Вы можете регистрироваться или как индивидуальный контрибьютор, или как компания. Очевидно, как российская компания там регистрироваться не стоит, иначе вас могут забанить навечно. Даже у нас в AxiomJDK есть с этим проблемы, поэтому мы не коммитим в OpenJDK, а поддерживаем свою кодовую базу. Но если вы хотите участвовать в этом на правах индивидуального исследователя. Если по вашим коммитам и тому, что вы пишите, очевидно, что вы не работаете на российскую компанию. То вы всё ещё можете попробовать зарегистрироваться как контрибьютор. Если у вас этого не получится, вы всегда можете пойти работать в AxiomJDK :) И здесь у вас таких проблем не будет.

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

Дальше вам нужно прочитать OpenJDK Developers Guide. Это огромный документ. Плюс от его чтения, что там объясняются все основные моменты. После прочтения, коллеги перестанут вас ненавидеть. Потому что вы перестанете задавать глупые вопросы.

Исходный код OpenJDK лежит на GitHub Поэтому его нужно склонировать как любой другой репозиторий И начать работать над ним Если ты всегда работал в каком-то центральном репозитории и не имел дела с форками, то на экране нарисован простой лайфхак Нужно сделать отдельный remote, который указывает на репозиторий основного проекта, не на твой форк И тогда у тебя будет возможность фетчить изменения из апстрима, без необходимости идти в веб-интерфейс Гитхаба

Дальше нужно запустить парочку скриптов. Конкретно, configure и make images. Как и что именно нужно запускать - подробно написано в README Единственный нюанс в том, что поскольку там происходит сборка нативного кода, инструкции по сборке сильно отличаются между разными платформами

Когда вы научились собирать и запускать JDK, стоит попробовать собрать и запустить какие-нибудь тесты. Чтение тестов способствует пониманию нюансов работы разных аспектов Джавы. Кроме того, можно самостоятельно законтрибьютить какой-нибудь тест. Это может быть сложно, но всяко проще, чем, например, сделать какое-то изменение в ядре JIT-компилятора

Код OpenJDK должен открываться и запускаться в большинстве современных IDE. Однако не ждите, что там всё будет гладко и хорошо, и всё будет подсвечиваться. Особенно, всё, что касается нативного кода и C++. И кстати, это хороший способ, как можно помочь - можно допилитьва эти плагины, чтобы они работали лучше.

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

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

Можно доносить свой фидбек по любым стандартным каналам. Самый важный способ - это писать в почтовые рассылки, о которых мы уже говорили. Кроме того, можно писать в соцсети, на реддит, в Твиттер, вам много кто может ответить. Один из самых интересных способов, про который обычно почему-то забывают, это создание контента в интернете. Если ты написал интересную статью или сделал яркий доклад, то тебя точно заметят.

Кстати говоря, Россия - это столица самых больших конференций, на которых говорят про Java. HighLoad - это одна из самых больших конференций про всё на свете, включая джаву Joker и JPoint - это самые большие конференции по Java в мире Я был на последних оракловских конференциях еще до ковида, и прямо скажем, их джавовские секции вызывали разочарование По сравнению с Хайлоадом и Джокером, это что-то типа сельской дискотеки Если вы собираетесь побывать в мире на джава-конференциях, то на контрасте с Хайлоадом не ожидайте чего-то необычного. === Кроме того, у меня в Санкт-Петербурге есть специальный бар для айтишников, который называется Failover Bar Я его владелец и мы постоянно делаем там всевозможные айтишные митапы. В том числе я делаю питерскую Джава Юзер Группу под названием Javawatch Поэтому, если вы каким-то образом попали в Санкт-Петербург, и вам хочется встретиться пообщаться про джаву со мной, или например, с нашим безопасником Александром Дроздовым. Это можно легко устроить, и общаться вживую, а не через интернет. Но самое важное, что на всех этих мероприятиях вы можете сами сделать доклад И это один из самых простых и действенных способов донести информацию до разработчиков. Если вам нужна помощь с докладом на любое из этих мероприятий. Вы не уверены, что говорите правильные вещи, или вам нужно помочь нарисовать слайды, или что-то еще в таком духе - свяжитесь со мной. У нас есть коллектив людей, которые помогают с такими вопросами, мы вам поможем.

Самое лучшее место для общения на русском языкыке в интернете про джаву - это Хабр. Точнее, его хаб Java. Если вы хотите писать статьи, то вам нужен будет инвайт. Если у вас инвайта еще нет. Можете написать мне или Бумбуруму, и мы найдем вам его выдадим. На слайде есть контакты, куда нужно писать.

Ну и наверное, в конце - пара слов о том, чем мы занимаемся в России. За последний год у нас ушли все зарубежные вендоры, которые делали джавовую инфраструктуру. Дистрибутивы JDK, сервера приложений, базовые образы докер-контейнеров, и так далее. Кроме того, российские компании больше не могут ничего закоммитить в апстрим OpenJDK, без дополнительной помощи. Вознкла проблема: если на проде у вас что-нибудь навернется, то остается писать только в Спортлото. Эту проблему решает команда Axiom JDK. Решает тем, что производит полный стек джава-технологий, которые можно использовать в России. В команде AxiomJDK работают инженеры, которые разрабатывают Джаву уже по два десятка лет. Они начинали в Оракле, и сейчас продложают работать здесь. Мы сделали замену основным компонентам джавовой инфраструктуры. Вместо Oracle JDK можно использовать AxiomJDK, вместо Вебсферы и Веблоджика - Либеркат, запустить всё в Axiom Runtime Container, и так далее.

Вместе это позволило добавить все эти штуки в реестр российского ПО и доработать до соответствия требованиям регулятора. Если кто-то знает, что ФСТЭК, то Аксиома позволяет вам писать объекты критической информационной инфраструктуры вплоть до 4 уровня доверия. Я не буду здесь об этом долго рассказывать. Все кому интересно, могут подойти и пообщаться в кулуарах. Суть в том, что если вам вдруг хочется поработать над разработкой Java, и разбираетесь в деталях реализации JVM, то вы можете прийти в AxiomJDK, и заниматься своей любимой работой за деньги.

Связаться с командой AxiomJDK можно в Телеграме Причем, если у вас какой-то серьезный рабочий вопрос Не пишите в мессенджеры, пишите на почту В мессенджерах слишком много сообщений, их невозможно все прочитать Если хочется просто пообсуждать джаву, сделать доклад на митапе, и так далее - заходите в чатик джававоча, я вам отвечу