А есть ли здесь те, кто подписан на этот канал, но не подписан на основной? Напоминаю, что канал microJUG второстепенный, а основной канал – это miniJUG. Так что если вы каким-то образом попали на этот канал и пропустили основной, то обязательно кликайте по ссылке и подписывайтесь на @miniJUG.

Один ответ остался

В Украине заблокировали GitHub

В перечень подпавших под блокировку доступа сайтов сайт статистики мессенджера Telegram и страница шеринга строк кода на международном IТ-ресурсе GitHub
https://www.interfax.ru/amp/753485

Николай Парлог теперь девелопер адвокат в Java Group в Oracle

Тут открыта позиция директора в команде Java Technical Product Marketing в Oracle. Требования тривиальные: нужно знать английский и жить в США/Канаде, 10 лет опыта в продажах или продуктовом менеджменте. В общем, откликайтесь на вакансию, пока не исчезла!

😂 #юмор

Ну что, теперь наконец-то Java не будет жрать память? 🤔
TLDR: хотят уменьшить заголовок объектов с 12 байт до 8 или даже 4-х.

Накладные расходы по памяти различных коллекций Java

То есть сколько нужно байт, чтобы создать коллекцию из N элементов (в данном случае 10) без учёта размера самих объектов.

Как видно из диаграммы, абсолютными чемпионами по неэффективности являются HashSet, TreeSet и LinkedHashSet. Они обходятся в 4-10 раз (!) дороже, чем эффективные коллекции из левой части. Так что в следующий раз задумайтесь, действительно ли вам нужно использовать именно их.

Из левого списка победителями стали List.of() и ImmutableList. Вот их и надо использовать почаще. Integer[] - для тех, кто экономит каждый байт.

Особняком стоит EnumSet и занимает даже меньше, чем массив. Там если в enum ≤ 64 элементов, то используется простой long для битовой маски.

Помните Украина заблокировала GitHub? Похоже, теперь эстафету дебилизма приняла Россия.

Когда тимлид потребовал документировать все публичные методы в проекте
#юмор

Ура, в @miniJUG более 1000 подписчиков! 🥳

Ну что, вы уже выставили глобальную переменную JAVA_TOOL_OPTIONS=--illegal-access=permit?

Помните недавно я сокрушался про Lombok, который не работает на Java 16? Вчера сразу после выхода Java GA появился патч, который чинит этот баг. Ну как чинит, там опять обходные пути и сплошная грязь 💩. Но давайте по порядку, т.к. там немного нетривиально.

Итак, 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(), передав туда наш модуль и имя пакета. Однако возникают следующие проблемы:

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 в целях безопасности, и поле override стало невидимым для reflection (чтобы кто попало не мог своими грязными ручонками вот так делать setAccessible, доступаясь до чего угодно: мы видите ли тут всё гайки закручиваем, а эти гады продолжают обходить и обходить).
5. Так что же делать? И вот тут самое веселье (такой хак мне ни за что не пришёл бы в голову). Нам ведь нужно просто передать offset поля, а это просто обычный long. Давайте как-нибудь посчитаем, какой offset имеет это поле в объекте Method. Как? Очень просто: объявим где-нибудь на нашей стороне класс с точно такими же полями, как и у Method (и на всякий случай в том же порядке), и найдём offset boolean поля для этого класса! Как тебе такое, Илон Маск? Ну а что: есть два класса с одинаковыми полями – значит JVM должна разложить эти поля по оффсетам в этих двух классах идентично.

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

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

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

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

#lombok #java16 #unsafe