Thread by @dbg_nsk

Пообщался на той неделе с @olegchir и в очередной раз понял, что про нас жутко мало известно людям, только какие-то мифы и легенды.

Хотите тред о разработке независимой JVM в святой Сибири?

1 лайк = 1 segfault, т.е. факт

0) Вообще, в Новосибе есть аж три команды JVM-инженеров (повод для гордости за свой город, между прочим), поэтому уточню: речь пойдет об @ExcelsiorJET

0.5) Ну и все, что я буду говорить, это только мое мнение, не стоит мне уж сильно верить, к тому же я под NDA, бла-бла-бла.

1) краткая справка: JET - полноценная (полностью соответствует спеке) JVM, главная фишка которой - ставка на AOT компиляцию (по максимуму компилируем классы заранее). Делаем мы ее в Новосибирском Академгородке, силами небольшой но гордой команды *минутка рекламы закончилась*

2) В данный момент над JET работают:

11 Инженеров,
2 Стажера,
2 QA/QE,
и еще 2 человека занимаются продажами

Полный список разработчиков за все время гораздо шире и включает Оззи Осборна (хотя он почему-то не приходит на корпоративы)

3) Клиенты у нас по всему миру, но вот в России их почему-то немного.
У нас даже предусмотрена премия тому, кто приведет первого "местного" клиента из академа. Но за все годы существования JET-а, никто ее так и не получал.

4) Кстати, JET - довольно взрослый проект. Первая версия вышла еще в 2000 году, а сейчас на подходе версия 15.3. Changelog за все годы очень впечатляет, конечно (его можно почитать, например, здесь: excelsiorjet.com/changelog).

4.1) По сhangelog, кстати, можно найти момент (JET 4, 2005 год), когда в JET стали уважать спеку и отказались от всяких очень крутых (но не очень корректных) оптимизаций. Привет, GraalVM!

4.2) Вообще, про историю JET лучше расскажет, например @pjBooms. Я то в Excelsior недавно, всего 7 лет, так что был очевидцем только недавних событий.

5) Ставка на AOT сильно все меняет, конечно.

Последние несколько лет наконец кто-то кроме нас стал говорить про AOT компиляцию Java. Забавно наблюдать, как люди впервые сталкиваются с проблемами тех же клинитов (и очень удивляются!), хотя для нас то это всегда было важно.

6) В JET огромное количество компиляторов на любой вкус и цвет, при чем их количество иногда меняется. Оптимизирующий компилятор написан на Scala, baseline на Java, есть свой форк javac, есть отдельный тул для статического анализа, есть всякие трансляторы кода, да много всего

6.1) Про baseline, кстати, есть забавная история. Мы его вслух часто называем "вазелин", а ситуацию, когда метод ушел по backup-path
в компиляцию бейзлайном - "метод завазелинился". Со стороны звучит странно, конечно, так что люди удивляются =)

7) Очень распространенный миф про Excelsior JET: да у вас там все на Обероне написано!

Ерунда, конечно, на Обероне написан всего один из компиляторов, и это легаси. Молодые инженеры туда заходить не любят (вы бы тоже не любили).

8) Забавный факт: инженеры в JET-team - не очень хорошо шарят в современных Java enterprsie технологиях (мы реализуем Java, а не используем ее).

Популярная шутка: прокричать на работе "есть здесь Java разработчик?".
Все смеются, потом плачут.

8.1) К счастью, теперь один из инженеров полноценно занимается изучением Java мира и прикручиванием всяких популярных штук к JET.
Правда из-за этого @pjBooms на стоячих собраниях использует всякие непонятные слова из мира enterprise, какие-то микросервисы, спригбуты, вот это все.

9) Мы в Excelsior очень любим делать все свое. Своя билдсистема (кстати, редкий шанс пописать на Java, допиливая что-то в ней),
своя бенч-система, своя система мониторинга, свои отладчики, свои профайлеры, свои гуи т.д. Мы называем это Excelsior Way, вон даже стикер есть (свой):

10) Команда JET довольно жестко разделяется на две взаимодополняющие группы: разработчики компилятора(-ов) и рантайма (gc, синхронизация, загрузка классов и т.д.). Компиляторщики более цивилизованные конечно, разрабатывают и отлаживают свои компиляторы в идее, как белые люди.

10.1) А в рантайме мы чаще сидим в GDB и отлавливаем развалы. Либо логи читаем. Но ведь в этом и кайф! да? да!? да. (плачет)

10.2) В случае бага компиляторщики надеются, что виноват рантайм; А рантаймщики, что это компилятор сгенерил кривой код, как он мог. Подколы про время компиляции или грязные хаки в рантайме соответственно присутствуют. Но на самом деле мы, конечно, делаем одно дело и дружим.

10.3) финальный вопрос по этой теме, к кому относится разработчик JIT-компилятора? к рантаймщикам или компиляторщикам? Недавно спросил у @liontiger23, он себя определил как рантаймщик, еее

11) Сколько у вас идет билд проекта? Мне нужно где-то полтора часа, чтобы собрать JET, скомпилировать им все платформенные классы и
запустить базовые тесты. И это только на одну платформу (из 6 возможных). Мы называем это checkin-test (по историческим причинам).

11.1) Конечно есть способы получить JET и побыстрее, но все равно учишься аккуратнее писать код, и сначала думать, а уж потом запускать сборки. Еще у меня есть привычка запускать CT перед тем, как выхожу на работу утром.

12) Все инженеры в команде JET - выпускники (а кто-то еще студент) ММФ или ФФ НГУ. Это наш способ поиска сотрудников: взять способного студента, позвать на стажировку и за несколько лет превратить в JVM инженера. Этому помогает и тот факт, многие из инженеров преподают в НГУ

12.1) Почему у нас нет студентов с ФИТ-а - большой вопрос. Думаю, про нас там просто не знают, а рассказать некому.

Фитовцы, вы это, заходите, если чо.

13) За время стажировки юный падаван:

-- Пишет реферат по какой-нибудь крутой (настоящей) статье на компиляторную или рантаймовскую тему,
-- Со временем допускается до коммита в мастер и делает хотя бы одну правку, которая улучшает JET в продакшне

[1/3]

-- Под руководством инженера делает крутой ресерч, который ложится в основу его диплома (защищает его на 5, конечно)
-- В идеале продуктизирует свой диплом, добавляя его в JET. Это не всегда случается, т.к. не любой ресерч сразу можно/нужно продуктизировать.

[2/3]

-- Выковывает свой первый световой меч и становится частью JET-core team!

Кстати в этом году защитился (и кстати продуктизировал свой диплом) мой студент, @GlushkoAl! Это здорово, даже не смотря на всякую бумажную работу, которую приходится делать.

14) В JET все время происходит какой-то ресрч, не только студентами, но и вообще. Например, сейчас @conwor и @noinline улучшают code scheduling, при чем по новейшей науке. До этого мы с нуля научились профилировать код с низкими издержками, сделали PGO, все время что-то новое.

14.1) При этом пока никто из нас не защитился, хотя у каждого есть материал на диссер другой. Защита - это огромное количество бумажной работы, которая отнимает время от дальнейшего ресерча. Так ли важна бумажка, когда ты можешь своими руками воплощать крутые технологии в жизнь?

15) в Excelsior много крутых традиций. Например, каждый год проводится хакатон, на котором все разбиваются на команды и делают проекты на любые темы

Конечно же инженеры JET-team чаще всего делают что-то необычное, но все равно связанное с JET, на что обычно не хватает времени

15.1) За все годы сделали просто кучу крутых проектов, от частичной поддержки JMVTI до порта JET-а на новую платформу (да, да, за пару дней).

Кстати, скоро уже хакатон, надо бы начинать готовиться.

16) Другая традиция в последний день RP перед релизом садиться и всей командой играть в скомпилированный JET-ом Jake2 (это порт второй кваки на Java). Технически, это - часть тестирования, у кого-то может что-то развалиться, и нужно будет отлаживать (такое бывало).

17) Еще мы очень любим придумывать всякие прикольные имена для build-машин. Например, есть пара серверов Mufasa и Scar, а тестовая ферма Raspberry PI состоит из машин Chip, Dale и Dory (у последней вечно какие-то проблемы с памятью):

17.1) а Scar появился ровно в тот день, когда Mufasa сломался (имя выбрали до этого). Линуксовые сервера Force и Impulse, бенчсистема Chronos, в общем да, имена выбирать мы любим

18) В Новосибе сейчас 3 часа ночи, так что, прервусь до завтра. Если у вас есть какие-нибудь вопросы про JET, можете пока написать, постараюсь завтра ответить!

19) Спрашивают, зачем нужна еще одна JVM, и кто наш потребитель.

Основные преимущества JET:

-- Быстрый стартап из-за AOT (при этом хорошая производительность и после старта, а не как у некоторых)

-- Protection: исходный код вы не достанете никак

-- Меньше memory footprint

19.1) Некоторые пользователи также очень ценят, что JET позволяет распространять их Java приложение без JRE, да еще и в виде красивого инсталлятора

20) О protection. С завидной постоянностью нам пишут крутые хакеры, обещающие быстренько сломать JET-скомпилированное приложение и достать исходный код. Результат немного предсказуем.

После всех оптимизаций, от вашего Java кода остается фарш, который обратно в барана не собрать.

20.1) И на самом деле мы идем в этом еще дальше. Есть опции, чтобы скрывать информацию из стектрейсов, чтобы криптовать строки и т.д.

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

21) Мы очень гордимся своим саппортом! Дело в том, что на письма клиентов отвечают сразу дежурные по саппорту JVM-инженеры, без какой-либо первой линии. Так что выключить и включить обычно никто не предлагает, сразу к сути.

22) Вообще, сидеть на саппорте - это очень полезное занятие. Понимаешь, что реально беспокоит клиентов, это возвращает на грешную землю.

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

23) Ну и конечно саппорт - это источник абсолютно крутых и иногда смешных детективных историй. Чего стоит хотя бы "Божья папка" (excelsiorjet.com/blog/support-s…) или недавняя история про финализацию, про которую я никак не соберусь написать пост

24) Отдельно отмечу, что многие авторы JET сейчас работают в смежных (и не менее интересных) проектах в Excelsior, что в том числе делает возможным существование JET. Ни в коем случае не хотел вас обидеть изначальным твитом, вы крутые.

https://twitter.com/dbg_nsk/status/1043195197830713344

25) Мы довольно фанатично относимся к своей работе, задержаться до допоздна - это вполне в порядке вещей.

Но это не очень хорошо стыкуется с пропускной системой на ВЦ. Вот недавно вечером с @FOODzzzEATamA и @liontiger23 выходили через окно, т.к. все уже было закрыто.

25.1) Но в целом охранники и вахтеры к нам привыкли за все эти годы. Обычно просто говорят "а, это вы, ну сколько вас там еще?", когда вечером сдаешь ключ. Либо шутят про трудоголизм, когда приходишь на выходных.

26) Кстати, многие из JET-team есть в тви: @cypok, @liontiger23, @FOODzzzEATamA, @pjBooms, @dleskov, @noinline, @conwor, @ivan_2804, @xappymah, @GlushkoAl Подписывайтесь!

27) Отлаживать JET-compiled приложения непросто (помните, protection, код после оптимизаций, все дела). Кроме того, своя схема устройства фреймов не позволяет нормально смотреть backtrace в gdb, так что приходится проявлять смекалочку

27.1) Раньше у нас был свой классный (гуевый!) отладчик. Но с ростом количества платформ поддерживать его стало тяжеловато.

Недавно мы сделали здоровенный плагин к gdb, знающий особенности JET. Позволяет делать вещи, например дергать методы из рантайма. Удобно и работает везде.

28) Но, конечно, не для всех багов вообще подойдет отладчик. Немного ошибешься в GC и получишь спорадичный развал, проявляющийся раз в пару недель и каждый раз в новом месте. Мой рекорд - баг, который проявлялся раз в год (не до конца уверен, что он пофиксан, год еще не прошел)

28.1) В таких случаях оставляешь "ловушки": кучу логирования всего подряд, срабатывающего при развале, чтобы в следующий раз лучше понять ситуацию. core dump тоже помогает, но он не всесилен.

29) Как тестируется JET? У нас гигантское количество различных тестов, начиная с юнит/функциональных, заканчивая JCK и автоматическим протыкиванием скомпилированных приложений. Тестами отлавливается огромное количество проблем, это бесценно.

29.1) При этом для подготовки такого тестсьюта тоже нужна серьезная экспертиза в JVM и конкретно в JET. Так что руководит QA/QE отделом опытный рантайм-инженер - @xappymah

30) Ну и конечно бенчи: у нас есть специальный бенчсет, который каждую ночь замеряется, туда можно добавлять свои сборки. Измеряется производительность, время компиляции, размер exe и memory-footprint. В теории перед коммитом правок нужно проверить, что ничего не просело.

30.1) для ситуации, когда закоммитал правки без предварительных замеров, а в результате бенчи просели, у нас есть специальное слово - "законворить".

Откуда оно появилось? Спросите у @conwor ;)

31) Компилятор в JET написан на scala/java, а значит... его тоже можно и нужно компилировать JET-ом! В таком виде он и поставляется. У нас также есть специальный бенч, где мы компилируем свой компилятор своим компилятором, а потом замеряем, как получившийся работает (компилирует)

32) В команде есть небольшой клэш имен. У нас:

3 Владимира
3 Ивана (при том все сидим в одном кабинете)
теперь еще 2 Никиты

Спасаемся никами и добавлением порядкового номера/первой буквы фамилии. Но стереотипы о русских Иванах и Владимирах прям напрашиваются!

33) Ну, нет, ненависти нет никакой. Нужны JVM хорошие и разные.

Лично мне кажется, что вокруг GraalVM слишком много хайпа, при том он не очень честный (говорят про хорошее, молчат про плохое).

Ну и нарушение спеки - это опасный путь, мы это проходили

https://twitter.com/skchrko/status/1043377640818786304

33.1) А по поводу конкурентов, ну сколько у них клиентов, конкретно у SVM? От прикольной игрушкой/ресерч проекта до готового продукта - очень долгий путь, им его еще предстоит пройти.

34) В спеке есть очень много моментов, подразумевающих вольность реализации. Например, нигде ведь не сказано, в каком порядке нужно выполнять finalize методы? У нас с HS этот порядок не совпадает, а люди на это затачиваются, в результате segfault (хотя на HS все работает).

35) Вообще, финализторы - это боль, конечно. Их не просто так задепрекейтили! Что только люди с ними не делают, как только не извращаются (крик души рантайм инженера)

36) Когда думал, что будет 5 лайков от коллег, вы вместе посмеетесь над локальными шутками и все, но что-то пошло не так. Продолжим вечером!

37) Мы публикуем довольно много информации о внутреннем устройстве JET-а и разных интересных случаях. Как в виде научных статей (хотя сейчас меньше, чем раньше), так и в виде постов в блоге.

38) Современный технический блог Excelsior JET здесь: excelsiorjet.com/blog/

Мы перезапустили его чуть больше года назад и стараемся периодически публиковать лонгриды. Скоро будет большой пост от @conwor, и это будет первый настоящий компиляторный пост! Подписывайтесь, в общем.

39) Была мысль дублировать посты на Хабре на русском, но как-то до этого руки пока не доходят.

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

40) Еще немного о саппорте: на саппорте по очереди дежурят все, включая руководителя проекта (он даже больше остальных).

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

41) Платный саппорт подразумевает ответы на вопросы, раскопки проблем (не всегда оказывается виноват JET), доставку клиенту фиксов и новых версий. Конечно, по мере возможности помогаем не только клиентам, но и тем, кто ещё только пробует продукт или получил лицензию бесплатно.

42) Бывают случаи, когда инженеры приезжают к клиентам и саппортают на месте. Недавно вот @pjBooms так ездил, красота!

43) Иногда люди в саппорте, после того, как поймут, что проблема на их стороне, начинают просить помочь разобраться багами в их коде.
Этому еще способствует, что саппортный адрес java[at]excelsior-usa.com, так что типа саппорт по Java.

44) Кстати, JET можно получить бесплатно, если используете его в реальном публичном некоммерческом проекте. Кроме того, есть специальный Standard Edition, который вообще бесплатный (правда там, конечно, нет многих оптимизаций).

45) У нас не коммитается код без ревью кроме, возможно, каких-то совсем редких и мелких исключений. Это очень серьезно, из-за необходимости ревью может даже немного сместиться дата очередного релиза.

46) Парное программирование тоже практикуем, но не так часто (нас банально не очень много). Интересный вопрос, отменяет ли парное программирование ревью? Я лично считаю, что нет.

47) Не любой компилятор, написанный на Java обязательно хорош. Вы видели сорцы javac? Там немного ад. Я, кстати, абсолютно не понимаю, почему так. Ведь он должен быть простым и хорошим.

48) Огромное количество злых багов случается из-за использования клиентами JNI. Там очень просто ошибиться (ну он правда неудобный).
Все ухудшается тем, что у нас более жесткие проверки стоят в реализации JNI (на HS для этого нужно включать -Xcheck:jni, а у нас сразу ломается).

49) У нас задолго до Jigsaw платформа была побита на части (и компилировалась каждая в отдельную dll).

50) Факт от отцов основателей: самая первая продажа JET случилась прям вечером в день выхода версии 1.0, когда ещё не все с работы разошлись. Ну и поехали отмечать это дело, естественно.

51) Из всех поддерживаемых OS меньше всего люблю Мак, т.к. для него в рантайме приходится делать всякие жуткие хаки. Чего стоит один тот факт, что нужен отдельный тред для обработки ивентов от Сocoa. И это должен быть main тред!

51.1) Вообще, мне кажется, на OS X просто все сделано для осложнении жизни системным программистам, которые не используют xcode.
И они дропнули поддержку gdb из коробки, ну как так :(

52) Кстати, наш плагин для gdb - тоже был изначально проектом на hackday. Потом в течение полугода я ходил и убеждал людей попробовать поотлаживаться в нем, вдруг понравится? Было похоже на религиозную пропаганду, как у свидетелей Иеговы. Но сработало же!

53) Мы в JET очень любим чатики в телеграме. Сейчас посчитал, я состою в 22 чатиках с префиксом Excelsior, может у кого-то больше.

Чат про компилятор, про рантайм, про блог, про учебу, про профайлеры, про GC. В общем, больше чатов Богу чатов!

54) В Excelsior работают очень крутые спецы. При этом, чем опытнее человек, тем больше у него контекст, тем он, понятно, круче.

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

54.1) Мне лично очень обидно, что многие из них мало выступают с докладами, особенно последнее время.

55) Простой тест на JVM инженера:

Покажите человеку вот такую гифку.
Если он начинает протестовать и кричать "эй, тут не так должно быть!!",
либо смеяться, то перед вами явно JVM инженер.

55.1) Это был пример Java2Demo (демка из jdk), скомпилированного компилятором с некорректной оптимизацией тестов, поэтому картинки кривые.

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

Ну, немного профессиональный юмор, да =)

55.2) Недавно пытался на словах объяснить стажеру, как должен проходить Java2Demo (почему-то сразу проверить на HS не посоветовал).

Со стороны, наверное, выглядело очень глупо: "вот видишь, кубы. Они должны быть... ну.. кубами".

Но на самом деле реально запоминаешь эти картинки

55.3) Вот, кстати, еще пример кривых Java2Demo от @pjBooms и @noinline:



Сам доклад тоже отличный, посмотрите.

56) Кстати, про клиентов в Академе. Как-то наш руководитель нашел в ТЦ диск с пиратским JET-ом. Такое вот своеобразное признание. Где-то до сих пор этот диск лежит.

57) Интересный challenge для AOT - время компиляции. С учетом всех глобальных оптимизацией оно может быть слишком большим.
Мы решаем эту проблему с помощью инкрементальной компиляции: при повторной компиляции компилируется гораздо меньше классов, только то, что реально поменялось

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

58) Про локальные термины. Кроме вазелина, мы используем:

"кролик" - пример, на котором воспроизводится проблема;
"сослать в Сибирь" - перенести холодный код в конец метода;
"gc-points" вместо "safe-points" (как ни пытались, термин safe-points не приживается)

59) Кстати, мы точно знаем, сколько стоит добавление в JVM safe-points, т.к. помним версию JET, где их еще не было (да, это возможно).

60) За развал ночной сборки инженер получает специальную метку в виде жука, типа такого (только настоящего). Потом сидит с ним, пока кто-то другой не развалит ночную сборку, тогда метка переходит к нему.

61) Попасть к нам на стажировку совсем не просто. Нужно порешать задачки (с какого-то старого финала ACM), а потом пройти собеседование, возможно в несколько туров. Иногда студент сначала становится кандидатом в стажеры и должен еще доказать, что он норм.

61.1) Зато такой жесткий отбор позволяет найти студентов с хорошим уровнем и замотивированных. Пройти этот отбор сложно, но оно того стоит, конечно.

62) У нас в лицензии прописано, что параллельные компиляции на одной копии JET-а запрещены. Долгое время это не чекалось, потом решили добавить проверку. И как вы думаете, что случилось? У нас тут же развалилась вся ночная сборка (слишком много компиляций параллельно в тестах).

63) В Excelsior очень сильно помогают желающим выступить на конференции с докладом. Это и помощь в подготовке метериала,
советы от опытных спикеров, ревью слайдов, прогоны в узком кругу, а потом и перед всей компанией. Это очень ценно.

64) У нас есть ряд оптимизаций стартапа (кроме самой AOT компиляции). Например, на предварительном прогоне запоминаем, какие страницы памяти загружались, а потом заранее протыкиваем их на старте по порядку.

65) Основной ресерч в рантайме - это GC и вообще memory management. Притом этот ресерч часто доходит до продуктизации, т.к. дает реальные бенефиты на production.

66) Кое-что из этого ресерча мы публикуем, иногда получаем ответные посты/исследования.

Например, после поста про mm scalability (excelsiorjet.com/memory-manager…) появился ответный пост от разработчика OpenJ9 из IBM: curcuitousthoughts.blogspot.com/2018/07/double….

Вот так и должна выглядеть наука!

67) Одним из примеров продуктизации диплома про memory management является текущий основной GC в JET, который называется CoreBalance (крутое название). Это продуктизированный диплом @roaccess.

68) Вообще, кстати, вот здесь можно посмотреть список тем дипломов наших студентов (только самых последних еще нет): excelsior.ru/internship/deg…

69) Рядом лежат материалы спецкурса про компиляторы от наших инженеров: excelsior.ru/cc
Вообще, если вы находитесь в академе и интересуетесь темой, то рекомендую на него походить (он не только для студентов).
Лучше курса про трансляторы/компиляторы вы в Нск не найдете.

70) В Excelsior мы обычно используем Intel, а не AT&T формат записи ассемблерных команд. Понятно, что это дело привычки, но вот у нас так.

71) Вообще, ассемблерный код приходится читать довольно часто, конечно.
Со временем начинаешь быстро узнавать паттерны инструкций: вот это safe-point, вот это заполнение стекаллоцированного объекта, вот это виртуальный вызов.

72) В JET была офигенная фича Java Runtime Slim-Down.
Смысл в том, чтобы статическим анализом понять, какие компоненты из платформы не используются приложением, и выкинуть их из сборки.
В результате - минимальный размер .exe. [1/2]

72.1) Но просто так выкинуть все нельзя, это нарушение спеки. Поэтому эти компоненты складывались на какой-нибудь сервер, который указывал клиент, и, если они вдруг понадобятся, выкачивались оттуда прям налету (на деле такое происходило очень редко, но корректность сохранялась).

72.2) С появлением компактных профилей, смысла в такой фиче стало немного, так что сейчас она задепрекейтена. Но код пока не выкинули.

73) Кстати, у нас нет интерпретатора. Совсем. Да, такое тоже бывает.

74) А вот JIT есть, он нужен, т.к. мир открыт, и могут появится классы, которые надо заджитовать. И более того, вот прям сейчас идет работа по переработке и улучшению джита, так что в новом релизе он будет шустрым.

75) Абсолютное большинство сотрудников Excelsior живет в Академе или рядом (не знаю, считается ли, что Бердск рядом с академом?). Из JET-team, кажется, только я сейчас мотаюсь из города. Ну, что поделать, я изначально был "городским".

76) У нас интересная система нумерования версий. Обычно версию просто инкрементируется, но иногда случаются исключения. Были версии 7.2, 7.6, 11.3, вот следующая версия будет 15.3 (в этих цифрах есть логика на самом деле).

77) Основная разработка у нас идет в git, поэтому openjdk-шные репозитории лично мне кажутся не очень удобными из-за hg. Так что я радуюсь проекту Skara.

78) JET любят геймдевы, которые хотят писать игры на Java (из-за protection). Вот, например, люди обсуждают, что lwjgl должен работать c JET, и что это очень важно forum.lwjgl.org/index.php?topi…

79) Даже сам Notch когда-то пробовал JET для компиляции Minecraft (когда он был еще на Java) и остался доволен. Не помню, правда, чем дело кончилось.

https://twitter.com/notch/status/267651354619678720

80) У нас есть специальный JET Embedded Edition, который основывается на Open JDK вместо Oracle JDK. Ну и вообще, JET хорошо подходит
для embedded: быстрый стартап, маленький memory-footprint, поддержка arm (для этого нам и нужна тестовая ферма из Raspberry Pi).