На слайдах будет много ссылок Вы **не** успеете их сфотографировать Вот единственная ссылка, которая вам нужна Слайды сверстаны в 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 можно в Телеграме Причем, если у вас какой-то серьезный рабочий вопрос Не пишите в мессенджеры, пишите на почту В мессенджерах слишком много сообщений, их невозможно все прочитать Если хочется просто пообсуждать джаву, сделать доклад на митапе, и так далее - заходите в чатик джававоча, я вам отвечу