🆕 Sequenced Collections — решение 20-летней проблемы

JEP 431 добавил в Java то, чего не хватало с самого начала, а именно единый интерфейс для упорядоченных коллекций. Разберем, что изменилось под капотом.

🔹 Проблема, которую игнорировали

До Java 21 List и Deque имеют порядок обхода, но их общий суперинтерфейс Collection - нет. Set не гарантирует порядок, но LinkedHashSet и SortedSet — гарантируют. Единого API для "дай первый/последний элемент" или "обход в обратном порядке" не существовало.

Результат? Костыли:

// До Java 21
list.get(0) // List
deque.getFirst() // Deque
sortedSet.first() // SortedSet
linkedHashSet.iterator().next() // LinkedHashSet

🔹 Три новых интерфейса

JEP 431 внедрил в иерархию коллекций три интерфейса:

interface SequencedCollection<E> extends Collection<E> {
SequencedCollection<E> reversed();
void addFirst(E);
void addLast(E);
E getFirst();
E getLast();
E removeFirst();
E removeLast();
}

interface SequencedSet<E> extends SequencedCollection<E>, Set<E> {
SequencedSet<E> reversed();
}

interface SequencedMap<K,V> extends Map<K,V> {
SequencedMap<K,V> reversed();
Map.Entry<K,V> firstEntry();
Map.Entry<K,V> lastEntry();
Map.Entry<K,V> pollFirstEntry();
Map.Entry<K,V> pollLastEntry();
// ... и другие методы
}

Все методы (кроме reversed()) - это default методы, промоутнутые из Deque. Это обеспечило обратную совместимость.

▪️ Важнейший нюанс: reversed() возвращает view, а не копию.

Изменения в оригинале видны в reversed view. Под капотом это lightweight wrapper, который инвертирует индексы при обращении.

🔹 Интеграция в иерархию

Collection<E>
└─ SequencedCollection<E>
├─ List<E>
├─ Deque<E>
└─ Set<E>
└─ SequencedSet<E>
└─ SortedSet<E>
└─ NavigableSet<E>

Map<K,V>
└─ SequencedMap<K,V>
└─ SortedMap<K,V>
└─ NavigableMap<K,V>

🔹 SortedSet и SortedMap

SortedSet и SortedMap теперь имплементируют sequenced интерфейсы, но есть нюанс: методы addFirst()/addLast()/putFirst()/putLast() существуют лишь для того, чтобы бросить UnsupportedOperationException.

Liskov Substitution Principle: "Am I a joke to you?"

Но справедливости ради — Java Collections делает так уже давно:

— map.keySet().add() → UnsupportedOperationException
— Arrays.asList().add() → UnsupportedOperationException
— Collections.unmodifiableList().set() → UnsupportedOperationException

Это называется optional operations — когда методы есть, но работать не обязаны. Документация прямо говорит:

Many methods will throw UnsupportedOperationException if the operation cannot be performed.

Альтернативы были хуже: либо создавать зоопарк из ReadOnlySequencedSet, MutableSequencedSet, PartiallyMutableSequencedSet, либо оставить SortedSet за бортом единообразного API.

🔼 Sequenced Collections — это не революция, но эволюция. Они заполняют пробел, который был в Java с первой версии, делая API консистентным и предсказуемым (хотя не без подводных камней).

💬 Что думаете о новом API?

🐸 Библиотека джависта

#CoreJava

🐸 Библиотека джависта

#DevLife

🤫 SOLID-принципы простыми словами

Чистый, масштабируемый и поддерживаемый код — не просто идеал, а необходимость. SOLID помогает писать архитектуру, которая выдерживает рост и изменения без боли 👇

1️⃣ SRP — Single Responsibility Principle
🧩 Каждый класс отвечает за что-то одно.
📍 Пример: Employee хранит данные сотрудника, но не считает зарплату — этим занимается PayrollService.

2️⃣ OCP — Open/Closed Principle
🧱 Класс открыт для расширения, но закрыт для изменения.
📍 Пример: интерфейс Shape с методом calculateArea().
Новые фигуры (Circle, Rectangle) добавляются без правки существующего кода.

3️⃣ LSP — Liskov Substitution Principle
🦆 Подкласс должен полностью заменять родителя, не ломая логику.
📍 Пример: если Bird умеет fly(), то Sparrow должен уметь летать.
Но Penguin не должен наследовать fly() — нарушает LSP.

4️⃣ ISP — Interface Segregation Principle
🔌 Не заставляй клиентов реализовывать лишние методы.
📍 Пример: вместо интерфейса Worker с work() и eat(),
разделите его на Workable и Eatable.
Робот реализует только Workable, человек — оба.

5️⃣ DIP — Dependency Inversion Principle
⚙️ Зависим от абстракций, а не от реализаций.
📍 Пример: Switch работает с интерфейсом Switchable.
Ему всё равно, включает ли он лампу (LightBulb) или вентилятор (Fan).

💡 Освоив SOLID, вы начнёте проектировать системы,
которые не боятся изменений и масштабируются без боли.

🐸 Библиотека джависта

#CoreJava

🐸 Библиотека джависта

#DevLife

❓ Какие бывают гарантии доставки сообщений в Kafka?

В Kafka существует три уровня гарантий доставки сообщений:

1️⃣ At most once (максимум один раз)

Сообщение может быть потеряно, но никогда не будет обработано дважды. Producer отправляет сообщение и не ждет подтверждения (acks=0). Самый быстрый, но ненадежный вариант.

2️⃣ At least once (минимум один раз)

Сообщение гарантированно доставлено, но может быть обработано несколько раз. Producer ждет подтверждения от лидера (acks=1) или всех реплик (acks=all). При повторной отправке возможны дубликаты. Используется чаще всего.

3️⃣ Exactly once (ровно один раз)

Сообщение доставляется и обрабатывается строго один раз. Достигается через idempotent producer (enable.idempotence=true) и транзакции. Самый надежный, но с небольшим оверхедом по производительности.

Выбор зависит от задачи: для логов подойдет at most once, для финансовых операций — exactly once, для большинства случаев — at least once с идемпотентной обработкой.

🐸 Библиотека собеса по Java

#core

🔍 Просто о сложном: Record Class

Record-классы появились в Java 14 (вначале как preview, позже стабилизированы) и стали настоящим спасением от шаблонного кода.

Это лаконичный способ описать неизменяемые data-классы — без десятков строк с конструкторами, equals(), hashCode() и toString().

🔹 Зачем они нужны

Раньше, чтобы описать простой объект вроде User, нужно было писать шаблонный код:

class User {
private final String name;
private final int age;

public User(String name, int age) {
this.name = name;
this.age = age;
}

// геттеры, equals, hashCode, toString...
}

С record это выглядит так:

record User(String name, int age) {}

И всё — у вас уже есть:

— конструктор, геттеры, equals(), hashCode(), toString();
— неизменяемость полей;
— компактность и читаемость.

🔹 Ключевые моменты

▪️ record — это специальный вид класса, унаследованный от java.lang.Record.
▪️ Все поля — final, сеттеров нет.
▪️ Можно добавить собственные методы и статические фабрики.
▪️ Можно переопределить канонический конструктор для валидации.
▪️ Можно объявлять вложенные рекорды и использовать их в switch или pattern matching.

🔹 Под капотом

Record — это не просто “синтаксический сахар”. JVM видит его как финальный класс с приватными финальными полями и стандартными методами, но запрещает наследование (final) и предполагает неизменность.

Так JVM и JIT могут делать агрессивные оптимизации — объекты рекордов живут меньше, быстрее создаются и не требуют избыточных проверок на изменение состояния.

🔹 Подводные камни

— Record ≠ DTO везде

Если вы сериализуете/десериализуете через фреймворки (Jackson, JPA), убедитесь, что они поддерживают record (современные версии — да).

— Проблемы с неймингом

Для рекордов автоматически создаются методы-геттеры без префикса get. Например, для record User(String name) будет метод name(), а не getName().

Это ломает привычные JavaBean-паттерны и может вызвать проблемы с библиотеками, которые ожидают именно getName().

— Не подходит, если нужен мутабельный объект.

Для билдера или ORM-энтити используйте обычный класс.

— Не добавляйте бизнес-логику внутрь record.

Это data-контейнер, а не доменная сущность.

✔️ Когда можно использовать

— DTO между слоями;
— Результаты запросов к БД (projection);
— Ответы REST API;
— Ключи в Map и Set;
— В тестах и утилитах для временных структур.

❌ Не подходит:

— На практике редко используется из-за проблем с неймингом.
— Для ORM-сущностей, билдера, и изменяемых структур.

🐸 Библиотека джависта

#CoreJava

⌛ Сохраняйте шпаргалку по Thread

🐸 Библиотека джависта

#Enterprise