Похоже, в скором будущем ZGC станет production ready. Появился новый черновик JEP.

Похоже, Nashorn (движок JS) скоро уберут из JDK. Он стал deprecated в Java 11, а теперь его хотят выбросить совсем. Причина очень банальная: никто не изъявил желание его поддерживать.
Таким образом, они хотят убрать единственный движок JS из JDK, и все приложения, использующие JS, перестанут работать. И знаете что? Я даже не удивлюсь, если они реально возьмут и сделают это. Вспомните, например, как просто выкосили Java EE в Java 11. А чем JS лучше?

Вчера на конференции SnowOne узнал об очень интересной библиотеке, которая позволяет использовать синтаксис Java 9-14 и компилировать его в Java 8. Библиотека называется Jabel и создана нашим соотечественником Сергеем Егоровым. Поддерживается всё кроме рекордов (их поддержка запланирована на ближайшее будущее). По сути Jabel это агент, который инструментирует пару классов в компиляторе javac и заставляет его "думать", что все фичи выше 9+ относятся к 8-й версии. И всё. Весь код плагина занимает всего около 150 строк! Плагин хорошо работает в Идее. Если ещё включить нужную инспекцию, то можно также обезопасить себя от использования API, которое появилось позже Java 8 (например, StackWalker).

Интересный паззлер от Стюарта Маркса

1. Ответ ищите в реплаях.
2. Ещё одна причина не использовать внутренние именованные классы.

Кому-нибудь нужен JetBrains All Products Pack на 3 месяца? Есть лишний купон, не знаю куда деть. Напишите мне, если кому-то нужно.

Купон ушёл

Ух ты, срач Баруха и Тагира в Твиттере! К сожалению, не про Java, а про коронавирус 🦠.
Начало
Продолжение

Новые синтаксические возможности с Java 10 по Java 15 в одной картинке

Вот такой канал обнаружил на YouTube. Много всяких видео про Java на русском языке.

Чёрт, в новом Телеграме статистика канала доступна только для 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(), который создавал бы копию объекта на основе магии и в обход конструктора.