История изменений

Копипаста про Lombok:

Вчера сразу после выхода Java GA появился патч (https://github.com/rzwitserloot/lombok/commit/9806e5cca4b449159ad0509dafde81951b8a8523), который чинит этот баг. Ну как чинит, там опять обходные пути и сплошная грязь 💩. Но давайте по порядку, т.к. там немного нетривиально.

Итак, Lombok использует внутренности модуля jdk.compiler, так как ему для своего функционирования необходимо представление абстрактного синтаксического дерева Java и ещё много чего. Большая часть пакетов jdk.compiler модулем не экспортируется, и начиная с Java 16 доступиться до этих пакетов стало нельзя без использования флагов –illegal-access=permit или –add-opens. Можно было бы заставить пользователей руками передавать флаг javac -J–illegal-access=permit или -J–add-opens с перечислением 9 пакетов (com.sun.tools.javac.code, com.sun.tools.javac.comp…), но понятно, что такое решение максимум тянет на временный workaround. Поэтому был выбран другой путь: через reflection дёрнуть метод Module.addOpens() (https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/Module.html#addOpens(java.lang.String,java.lang.Module)), передав туда наш модуль и имя пакета. Однако возникают следующие проблемы:

1. Метод Module.addOpens() является CallerSensitive, и его может дёрнуть только код из самого модуля jdk.compiler, иначе вылетит IllegalCallerException. Что делать? Если посмотреть на реализацию метода Module.addOpens(), то можно увидеть, что он делегирует работу другому внутреннему методу Module.implAddOpens(), который уже не CallerSensitive. Поэтому давайте будем вызывать его!
2. Но как вызвать внутренний метод, если теперь у нас внутренности JDK закрыты? Method.setAccessible(true) выбросит InacessibleObjectException. Что делать? Давайте попробуем сделать метод accessible через Unsafe! Сделать это можно так: в классе AccessibleObject (от которого отнаследован Method) есть поле boolean override. С помощью Unsafe это поле можно переключить с false на true, используя метод Unsafe.putBooleanVolatile. Давайте так и сделаем.
3. Но не всё так просто. Чтобы вызвать putBooleanVolatile, нужно передать ему offset этого поля, получить который можно через другой метод Unsafe.objectFieldOffset.
4. Вроде справились? Ещё нет. Чтобы вызвать Unsafe.objectFieldOffset, нужно иметь на руках объект Field для поля override. Но тут вроде всё просто? Получить Field можно просто вызвав AccessibleObject.class.getDeclaredField(«override»). Однако это не сработает: эту лавочку прикрыли в Java 12 (https://bugs.openjdk.java.net/browse/JDK-8210522) в целях безопасности, и поле override стало невидимым для reflection (чтобы кто попало не мог своими грязными ручонками вот так делать setAccessible, доступаясь до чего угодно: мы видите ли тут всё гайки закручиваем, а эти гады продолжают обходить и обходить).
5. Так что же делать? И вот тут самое веселье (такой хак мне ни за что не пришёл бы в голову). Нам ведь нужно просто передать offset поля, а это просто обычный long. Давайте как-нибудь посчитаем, какой offset имеет это поле в объекте Method. Как? Очень просто: объявим где-нибудь на нашей стороне класс с точно такими же полями, как и у Method (и на всякий случай в том же порядке), и найдём offset boolean поля для этого класса (https://www.youtube.com/watch?v=VWoMoRBx2D8)! Как тебе такое, Илон Маск? Ну а что: есть два класса с одинаковыми полями – значит JVM должна разложить эти поля по оффсетам в этих двух классах идентично.

Вот такой вот хак. И это даже работает.

А теперь посмотрим ещё раз, какие допущения использовались, и как легко это всё может развалиться:

1. В классе Module внутренний метод, отвечающий за логику открытия пакетов, называется implAddOpens. Если этот метод переименуют, добавят туда параметры или поменяют их порядок, Lombok сломается.
2. Класс AccessibleObject имеет внутреннее boolean поле, которое объявлено первым. Если это поле уберут, на первое место поставят другое поле, JVM начнёт компоновать поля как-нибудь по-другому или вообще логика AccessibleObject как-нибудь совсем поменяется – Lombok сломается.
3. А ещё, что есть Unsafe, который сам может когда-нибудь исчезнуть.

И ещё кстати это всё написано на Java 6, поэтому логика нахождения модулей, которая требует наличие таких классов как Optional, Module, ModuleLayer, реализована полностью через reflection.

Копипаста про Lombok:

Вчера сразу после выхода Java GA появился патч (https://github.com/rzwitserloot/lombok/commit/9806e5cca4b449159ad0509dafde81951b8a8523), который чинит этот баг. Ну как чинит, там опять обходные пути и сплошная грязь 💩. Но давайте по порядку, т.к. там немного нетривиально. Итак, Lombok использует внутренности модуля jdk.compiler, так как ему для своего функционирования необходимо представление абстрактного синтаксического дерева Java и ещё много чего. Большая часть пакетов jdk.compiler модулем не экспортируется, и начиная с Java 16 доступиться до этих пакетов стало нельзя без использования флагов –illegal-access=permit или –add-opens. Можно было бы заставить пользователей руками передавать флаг javac -J–illegal-access=permit или -J–add-opens с перечислением 9 пакетов (com.sun.tools.javac.code, com.sun.tools.javac.comp…), но понятно, что такое решение максимум тянет на временный workaround. Поэтому был выбран другой путь: через reflection дёрнуть метод Module.addOpens() (https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/Module.html#addOpens(java.lang.String,java.lang.Module)), передав туда наш модуль и имя пакета. Однако возникают следующие проблемы:

1. Метод Module.addOpens() является CallerSensitive, и его может дёрнуть только код из самого модуля jdk.compiler, иначе вылетит IllegalCallerException. Что делать? Если посмотреть на реализацию метода Module.addOpens(), то можно увидеть, что он делегирует работу другому внутреннему методу Module.implAddOpens(), который уже не CallerSensitive. Поэтому давайте будем вызывать его!
2. Но как вызвать внутренний метод, если теперь у нас внутренности JDK закрыты? Method.setAccessible(true) выбросит InacessibleObjectException. Что делать? Давайте попробуем сделать метод accessible через Unsafe! Сделать это можно так: в классе AccessibleObject (от которого отнаследован Method) есть поле boolean override. С помощью Unsafe это поле можно переключить с false на true, используя метод Unsafe.putBooleanVolatile. Давайте так и сделаем.
3. Но не всё так просто. Чтобы вызвать putBooleanVolatile, нужно передать ему offset этого поля, получить который можно через другой метод Unsafe.objectFieldOffset.
4. Вроде справились? Ещё нет. Чтобы вызвать Unsafe.objectFieldOffset, нужно иметь на руках объект Field для поля override. Но тут вроде всё просто? Получить Field можно просто вызвав AccessibleObject.class.getDeclaredField(«override»). Однако это не сработает: эту лавочку прикрыли в Java 12 (https://bugs.openjdk.java.net/browse/JDK-8210522) в целях безопасности, и поле override стало невидимым для reflection (чтобы кто попало не мог своими грязными ручонками вот так делать setAccessible, доступаясь до чего угодно: мы видите ли тут всё гайки закручиваем, а эти гады продолжают обходить и обходить).
5. Так что же делать? И вот тут самое веселье (такой хак мне ни за что не пришёл бы в голову). Нам ведь нужно просто передать offset поля, а это просто обычный long. Давайте как-нибудь посчитаем, какой offset имеет это поле в объекте Method. Как? Очень просто: объявим где-нибудь на нашей стороне класс с точно такими же полями, как и у Method (и на всякий случай в том же порядке), и найдём offset boolean поля для этого класса (https://www.youtube.com/watch?v=VWoMoRBx2D8)! Как тебе такое, Илон Маск? Ну а что: есть два класса с одинаковыми полями – значит JVM должна разложить эти поля по оффсетам в этих двух классах идентично.

Вот такой вот хак. И это даже работает.

А теперь посмотрим ещё раз, какие допущения использовались, и как легко это всё может развалиться:

1. В классе Module внутренний метод, отвечающий за логику открытия пакетов, называется implAddOpens. Если этот метод переименуют, добавят туда параметры или поменяют их порядок, Lombok сломается.
2. Класс AccessibleObject имеет внутреннее boolean поле, которое объявлено первым. Если это поле уберут, на первое место поставят другое поле, JVM начнёт компоновать поля как-нибудь по-другому или вообще логика AccessibleObject как-нибудь совсем поменяется – Lombok сломается.
3. А ещё, что есть Unsafe, который сам может когда-нибудь исчезнуть.

И ещё кстати это всё написано на Java 6, поэтому логика нахождения модулей, которая требует наличие таких классов как Optional, Module, ModuleLayer, реализована полностью через reflection.