Про версионирование в Java

Вот такой код был когда-то в Hadoop:

private static boolean IS_JAVA7_OR_ABOVE =
System.getProperty("java.version").substring(0, 3).compareTo("1.7") >= 0;

Не понимаю, как можно было в здравом уме такое написать в проекте такого уровня. Ну хорошо, предвидеть, что схема версионирования в Java поменяется, было довольно трудно. Но ведь даже если она не поменялась бы, то всё равно бы это работало неправильно! Допустим, вышла 1.8, потом 1.9, а потом 1.10. И для 1.10 IS_JAVA7_OR_ABOVE было бы false!

Аналогичный случай в commons-lang (версия 2.5). Там тоже используется substring. Для Java 1.10 SystemUtils.JAVA_VERSION_AS_FLOAT по старой схеме возвратило бы 1.1 (что меньше 1.7), а по новой это стало выбрасывать StringIndexOutOfBoundsException. То есть точно такой же баг. И это ведь библиотека, которую используют тысячи других проектов. Неужели нельзя было предвидеть, что когда-нибудь выйдет Java 10, и весь существующий код в мире просто сломается?

Результаты опроса по версиям Java. Java 11 сравнялась с Java 8 💪. В следующем году уже точно станет самой распространённой версией.

Очень странное ограничение в Java. Коллизий же никаких нет. Почему я не могу использовать статический импорт в данном случае?

P.S. Да, я знаю, что в JLS такое ограничение.

А есть ли здесь те, кто подписан на этот канал, но не подписан на основной? Напоминаю, что канал 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?