Чёрт, в новом Телеграме статистика канала доступна только для 1000+ подписчиков. А в miniJUG пока только 717. Ну что ж, значит будем расти.

Когда говорили, что не нужно использовать лишние зависимости без необходимости, но они не послушались.

Узнали? Согласны?

Плагин для IntelliJ IDEA, который заменяет стандартные иконки для специфичных типов файлов (gradle, git, Travis и т.д.)

Ещё один интересный плагин для Идеи: Laconic POM. Делает так, чтобы POM-файлы Maven выглядели более компактно.
#maven

Шёл 287-й день карантина...

Никогда не используйте Cloneable!

Тут Тагир Валеев написал в Твиттере, что clone() это неплохая штука, если ей правильно пользоваться. Я с этим категорически не согласен. clone() — ужаснейшая вещь. Попробую объяснить почему.

Давайте вспомним, что это вообще такое. Cloneable — наследие с самой первой версии Java. Это интерфейс, который позволяет легко добавлять возможность копирования объектов наших классов. Для этого мы просто наследуем класс от интерфейса Cloneable, и JVM с помощью некоторой магии генерирует нам реализацию метода clone(), которая будет делать копии путём простого копирования полей. При этом сам метод clone является protected методом в классе java.lang.Object, и поэтому доступен для каждого класса, в том числе для тех, кому клонирование нафиг не нужно (это 99% классов).

Здесь можно провести полную аналогию с сериализацией. Если в сериализации есть интерфейс Serializable, который не содержит методов и является интерфейсом-маркером, и при его реализации класс автоматически становится сериализуемым, то в этом случае есть интерфейс Cloneable, который тоже не содержит методов и также является интерфейсом-маркером, и при его реализации класс автоматически становится клонируемым.

Какие проблемы есть у такого механизма клонирования?

Во-первых, это отсутствие статических проверок. Можно забыть отнаследоваться от интерфейса Cloneable и спокойно при этом пользоваться методом clone(). Об ошибке мы узнаем только во время выполнения, когда вылетит CloneNotSupportedException.

Во-вторых, это необходимость downcasting’а при вызове метода clone(). Из-за того, что метод clone() в классе java.lang.Object возвращает Object, нам приходится делать явный cast, чтобы привести его к конкретному типу. Например, если вы вызовете ArrayList.clone(), то вам вернётся Object, а не ArrayList, и вам придётся скастовать к ArrayList. Во времена Java 1.0 это не казалось проблемой, поскольку тогда downcasting был совершенно привычной практикой, но сегодня большинство программистов старается избегать написания подобного нетипобезопасного кода.

В-третьих, так как в большинстве случаев, чтобы нести какую-то пользу, метод clone() должен быть публичным, то нам приходится переопределять метод clone() с одной лишь целью — изменить protected на public! При этом при переопределении метода clone() приходится писать абсолютно бесполезный код, в котором не делается ничего полезного кроме вызова super-метода и перебрасывания CloneNotSupportedException.

И это четвёртая проблема: CloneNotSupportedException является checked-исключением. Checked-исключения — это одна из вещей, от которой я бы тоже с удовольствием избавился в Java. От них вреда намного больше, чем пользы. Можно это как-нибудь позже более подробно обсудить. И если, в том, что, например, IOException является checked-исключением, есть хоть какой-то смысл, то в том, что CloneNotSupportedException сделали checked, смысла нет никакого. Заставлять каждый раз ловить CloneNotSupportedException при вызове clone() — чем думали создатели??

Какое есть решение у вышеперечисленных проблем? Решение простое — просто никогда не использовать Cloneable и метод clone(). Ну разве что за исключением клонирования массивов (это единственное исключение). В остальных случаях, если хочется иметь копирование, можно просто написать свой конструктор копирования или метод копирования, например назвав его copy(). Это будет намного лучше, прозрачнее и безопаснее, чем метод clone(), который создавал бы копию объекта на основе магии и в обход конструктора.

Стабильность, которой позавидует даже Путин
#юмор

(В 15-00 по Москве) 👇

Раскрыта правда об отце рэпера Моргенштерна!
#юмор

Марк Рейнолд объявил о новом проекте OpenJDK под кодовым названием Leyden. Цель проекта - уметь создавать из Java-программ самодостаточный статический образ с помощью AOT-компиляции. Похожая технология уже есть в GraalVM под названием Native Image, но она не будет использоваться при разработке.

Biased Locking всё

К сожалению, паттерны деконструкции для записей не появятся в Java 15. Об этом было написано в рассылке, а соответствующая секция была убрана из JEP'а.
Как сказал Gavin Bierman, там есть некоторые сложности с дженериками и varargs, и нужно ещё время, чтобы подумать над дизайном.
Это значит, что в Java 15 изменений в паттерн-матчинге не будет.

Решил составить список русскоязычных Telegram-каналов про Java. Добавил туда те каналы, про которые знаю сам. Но наверняка есть ещё. Если вы знаете, то напишите в комментариях, чтобы я добавил.

P.S. Про чаты писать не нужно, только каналы.