Ахах, в самой библиотеке Java есть синхронизация на value-based классах.
Это кстати говорит о том, что на коллекциях тоже не надо синхронизоваться, потому что там могут быть любые реализации, в т.ч. value-based.
Это кстати говорит о том, что на коллекциях тоже не надо синхронизоваться, потому что там могут быть любые реализации, в т.ч. value-based.
Недавно проводил опрос про Pair. А кто-нибудь знает про Either и использовали ли когда-нибудь?
Final Results
7%
Использовал в production, но не в Java (Scala, Kotlin и т.п.)
5%
Использовал в production в Java
15%
Я знаю, что такое Either, не использовал, но хотел бы использовать
9%
Я знаю, что такое Either, не использовал и не собираюсь (Either - зло, как и Pair)
65%
Не знаю, что это
В Украине заблокировали GitHub
В перечень подпавших под блокировку доступа сайтов сайт статистики мессенджера Telegram и страница шеринга строк кода на международном IТ-ресурсе GitHub
https://www.interfax.ru/amp/753485
В перечень подпавших под блокировку доступа сайтов сайт статистики мессенджера Telegram и страница шеринга строк кода на международном IТ-ресурсе GitHub
https://www.interfax.ru/amp/753485
Интерфакс
Украинских провайдеров обязали заблокировать РБК и 425 других ресурсов
На Украине Национальная комиссия по госрегулированию в сфере связи и информатизации (НКРСИ) проинформировала провайдеров, что они должны заблокировать доступ к 426 сайтам, среди которых сайт российского РБК, блогосервиса "Живой журнал" (Livejournal.com),…
Накладные расходы по памяти различных коллекций Java
То есть сколько нужно байт, чтобы создать коллекцию из N элементов (в данном случае 10) без учёта размера самих объектов.
Как видно из диаграммы, абсолютными чемпионами по неэффективности являются HashSet, TreeSet и LinkedHashSet. Они обходятся в 4-10 раз (!) дороже, чем эффективные коллекции из левой части. Так что в следующий раз задумайтесь, действительно ли вам нужно использовать именно их.
Из левого списка победителями стали List.of() и ImmutableList. Вот их и надо использовать почаще. Integer[] - для тех, кто экономит каждый байт.
Особняком стоит EnumSet и занимает даже меньше, чем массив. Там если в enum ≤ 64 элементов, то используется простой long для битовой маски.
То есть сколько нужно байт, чтобы создать коллекцию из N элементов (в данном случае 10) без учёта размера самих объектов.
Как видно из диаграммы, абсолютными чемпионами по неэффективности являются HashSet, TreeSet и LinkedHashSet. Они обходятся в 4-10 раз (!) дороже, чем эффективные коллекции из левой части. Так что в следующий раз задумайтесь, действительно ли вам нужно использовать именно их.
Из левого списка победителями стали List.of() и ImmutableList. Вот их и надо использовать почаще. Integer[] - для тех, кто экономит каждый байт.
Особняком стоит EnumSet и занимает даже меньше, чем массив. Там если в enum ≤ 64 элементов, то используется простой long для битовой маски.
Помните Украина заблокировала GitHub? Похоже, теперь эстафету дебилизма приняла Россия.
TJ
Роскомнадзор вместе с твиттером замедлил все сайты с «t.co» в домене, включая RT, Microsoft и GitHub — Новости на TJ
Похоже, «система замедления» ведомства просто перебирает все адреса с определённым сочетанием в домене.
Ну что, вы уже выставили глобальную переменную
JAVA_TOOL_OPTIONS=--illegal-access=permit?Помните недавно я сокрушался про Lombok, который не работает на Java 16? Вчера сразу после выхода Java GA появился патч, который чинит этот баг. Ну как чинит, там опять обходные пути и сплошная грязь 💩. Но давайте по порядку, т.к. там немного нетривиально.
Итак, Lombok использует внутренности модуля jdk.compiler, так как ему для своего функционирования необходимо представление абстрактного синтаксического дерева Java и ещё много чего. Большая часть пакетов jdk.compiler модулем не экспортируется, и начиная с Java 16 доступиться до этих пакетов стало нельзя без использования флагов
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 это поле можно переключить с
3. Но не всё так просто. Чтобы вызвать putBooleanVolatile, нужно передать ему offset этого поля, получить который можно через другой метод Unsafe.objectFieldOffset.
4. Вроде справились? Ещё нет. Чтобы вызвать Unsafe.objectFieldOffset, нужно иметь на руках объект Field для поля override. Но тут вроде всё просто? Получить Field можно просто вызвав
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
Итак, 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
Почему-то у нас только один Tonsky говорит про UX. Я тоже хочу.
Какой вот, например, сакральный смысл дублировать breadcrumbs в Идее? Причём второй breadcrumb какой-то урезанный, и, ИМХО, бесполезный. Можно убрать этот второй урезанный breadcrumbs и на его место перенести главный. В Eclipse именно так и сделано (второй скрин).
Результат: будет меньше визуальных элементов и будет сэкономлено драгоценное вертикальное пространство (для меня это важно - я работаю на маленьком ультрабуке).
#IntelliJIDEA #Eclipse #UX
Какой вот, например, сакральный смысл дублировать breadcrumbs в Идее? Причём второй breadcrumb какой-то урезанный, и, ИМХО, бесполезный. Можно убрать этот второй урезанный breadcrumbs и на его место перенести главный. В Eclipse именно так и сделано (второй скрин).
Результат: будет меньше визуальных элементов и будет сэкономлено драгоценное вертикальное пространство (для меня это важно - я работаю на маленьком ультрабуке).
#IntelliJIDEA #Eclipse #UX
Если бы у меня спросили назвать 10 главных классных фишек Идеи, то одной из них я бы однозначно назвал умение масштабировать свой UI на лету.
Проверить это очень просто: заходите в настройки дисплея в своей операционной системе, меняете масштаб со 100%, скажем, на 150%, и вуаля – Идея тут же подхватила изменения, и все шрифты, контролы, иконки стали выглядеть в 1.5 раза больше. А ещё более эффектно это можно продемонстрировать так: подключаете к компьютеру второй монитор с другим DPI (скажем, один монитор 4k, а другой FullHD) и начинаете перетаскивать мышью окошко Идеи туда-сюда с одного дисплея на другой и обратно. И Идея будет переключать свой scale прямо на глазах.
Но почему это для меня так важно, спросите вы? Я что, постоянно лажу в настройки и меняю туда-сюда масштаб? Да, только я не специально это делаю, а потому что у меня есть три разных компьютера, с которых я работаю. Главный компьютер стоит на работе, и там 4k монитор с 200%. Другие два – это домашний комп со 100% и ультрабук со 150%, которые подключены через RDP к рабочему. И вот я постоянно между ними переключаюсь: то лёжа работаю с маленьким ноутом, то стоя за компом, а иногда и на работу прихожу и там сижу за основным. И при каждом таком переключении Идея подхватывает DPI и переходит на правильный масштаб. Без рестарта. Казалось бы, это какие-то минуты в день, но всё равно приятно.
Впрочем, это не столько заслуга Идеи, сколько Swing'а, на котором она написана. Напомню, что в отличие от AWT и SWT, которые переиспользуют нативные контролы, в Swing все элементы рисуются поверх окошка программным образом. И я считаю, что это очень удачное решение. Точно так же, например, работает весь веб – браузеры рисуют содержимое страниц поверх окна, и поэтому тоже хорошо переключают масштаб. А вот 80% остальных приложений системы работают плохо, потому что используют нативный UI. Например, Telegram Desktop становится крошечным, и его приходится перезапускать. У Teams едет верхняя панель. JetBrains ToolBox становится мыльным. Ну и, конечно же, всё плохо с Eclipse, который является моей основной IDE.
Какой из этого вывод? Swing написан в конце 90-х, и там про слово HiDPI даже не слышали. Но они заложили фундамент – абстрагировались от натива и стали рисовать UI руками. И когда этот HiDPI появился, то его поддержку добавили относительно небольшими усилиями. Поэтому если вы просто запускаете старое Swing приложение на Java 9+ на HiDPI-дисплее, то автоматом получается красиво. Ну или почти автоматом. Иконки он, естественно, не перерендерит за вас. Swing их увеличит, и они станут мыльными. Поэтому вам придётся предоставлять HiDPI-версии иконок. Идея, кстати, использует SVG-иконки, поэтому её масштабировать можно как угодно, даже в некруглые масштабы типа 175% или 225%, и она во всех случаях будет выглядеть хорошо.
А что касается нативного Look and Feel, то я считаю, что он переоценён. Да, натив, это конечно, привычно и удобно для юзера, но в наше время большого количества девайсов гораздо важнее переносимость и кроссплатформенность. Да и нативный Look всегда можно сымитировать программно, если хочется. Вон, Swing на macOS выглядит вообще неотличимо от натива.
Впрочем, это ещё не ставит окончательный крест на SWT. Всё-таки это тоже абстракция, и нигде в спецификации не написано, что он обязан использовать нативные контролы. Приложив определённые усилия, можно реализовать отрисовку SWT-контролов аналогично Swing'у. Но нужен тот, кто готов вложиться в такой масштабный проект.
Проверить это очень просто: заходите в настройки дисплея в своей операционной системе, меняете масштаб со 100%, скажем, на 150%, и вуаля – Идея тут же подхватила изменения, и все шрифты, контролы, иконки стали выглядеть в 1.5 раза больше. А ещё более эффектно это можно продемонстрировать так: подключаете к компьютеру второй монитор с другим DPI (скажем, один монитор 4k, а другой FullHD) и начинаете перетаскивать мышью окошко Идеи туда-сюда с одного дисплея на другой и обратно. И Идея будет переключать свой scale прямо на глазах.
Но почему это для меня так важно, спросите вы? Я что, постоянно лажу в настройки и меняю туда-сюда масштаб? Да, только я не специально это делаю, а потому что у меня есть три разных компьютера, с которых я работаю. Главный компьютер стоит на работе, и там 4k монитор с 200%. Другие два – это домашний комп со 100% и ультрабук со 150%, которые подключены через RDP к рабочему. И вот я постоянно между ними переключаюсь: то лёжа работаю с маленьким ноутом, то стоя за компом, а иногда и на работу прихожу и там сижу за основным. И при каждом таком переключении Идея подхватывает DPI и переходит на правильный масштаб. Без рестарта. Казалось бы, это какие-то минуты в день, но всё равно приятно.
Впрочем, это не столько заслуга Идеи, сколько Swing'а, на котором она написана. Напомню, что в отличие от AWT и SWT, которые переиспользуют нативные контролы, в Swing все элементы рисуются поверх окошка программным образом. И я считаю, что это очень удачное решение. Точно так же, например, работает весь веб – браузеры рисуют содержимое страниц поверх окна, и поэтому тоже хорошо переключают масштаб. А вот 80% остальных приложений системы работают плохо, потому что используют нативный UI. Например, Telegram Desktop становится крошечным, и его приходится перезапускать. У Teams едет верхняя панель. JetBrains ToolBox становится мыльным. Ну и, конечно же, всё плохо с Eclipse, который является моей основной IDE.
Какой из этого вывод? Swing написан в конце 90-х, и там про слово HiDPI даже не слышали. Но они заложили фундамент – абстрагировались от натива и стали рисовать UI руками. И когда этот HiDPI появился, то его поддержку добавили относительно небольшими усилиями. Поэтому если вы просто запускаете старое Swing приложение на Java 9+ на HiDPI-дисплее, то автоматом получается красиво. Ну или почти автоматом. Иконки он, естественно, не перерендерит за вас. Swing их увеличит, и они станут мыльными. Поэтому вам придётся предоставлять HiDPI-версии иконок. Идея, кстати, использует SVG-иконки, поэтому её масштабировать можно как угодно, даже в некруглые масштабы типа 175% или 225%, и она во всех случаях будет выглядеть хорошо.
А что касается нативного Look and Feel, то я считаю, что он переоценён. Да, натив, это конечно, привычно и удобно для юзера, но в наше время большого количества девайсов гораздо важнее переносимость и кроссплатформенность. Да и нативный Look всегда можно сымитировать программно, если хочется. Вон, Swing на macOS выглядит вообще неотличимо от натива.
Впрочем, это ещё не ставит окончательный крест на SWT. Всё-таки это тоже абстракция, и нигде в спецификации не написано, что он обязан использовать нативные контролы. Приложив определённые усилия, можно реализовать отрисовку SWT-контролов аналогично Swing'у. Но нужен тот, кто готов вложиться в такой масштабный проект.
Теперь в Java у классов может быть 5 модификаторов. До sealed классов могло быть максимум 4.
#БесполезныйФактОJava
#БесполезныйФактОJava