☕️ Java Tips: Инициализация карты в одну строку с Map.of()

Помните, как раньше приходилось создавать Map с заранее известными значениями? Куча вызовов .put(), статические блоки или (не дай бог) двойные фигурные скобки. Начиная с Java 9, у нас есть красивый и лаконичный способ - Map.of().

Разберем, как это работает и, главное, чего нельзя делать.

🆚 До и После

Как было раньше (The Old Way):

Map<String, Integer> map = new HashMap<>();
map.put("One", 1);
map.put("Two", 2);
map.put("Three", 3);
// Результат: много строк кода ради простых данных

Как сейчас (The Modern Way):

Map<String, Integer> map = Map.of(
    "One", 1,
    "Two", 2,
    "Three", 3
);
// Результат: чисто, читаемо, одна инструкция

⚠️ Важные нюансы (Gotchas)

Использование Map.of() - это не просто синтаксический сахар для HashMap. Это создание неизменяемой (Immutable) структуры.

1. Нельзя менять данные
Попытка добавить или удалить элемент приведет к ошибке.

var colors = Map.of("Red", "#FF0000");
colors.put("Blue", "#0000FF"); 
// ❌ Ошибка: UnsupportedOperationException

2. Никаких null
В отличие от HashMap, здесь нельзя использовать null ни в ключах, ни в значениях.

Map.of("Key", null); 
// ❌ Ошибка: NullPointerException

3. Лимит в 10 пар
Метод Map.of() перегружен для приема до 10 пар ключ-значение. Если нужно больше, используйте Map.ofEntries():

Map.ofEntries(
    Map.entry("k1", "v1"),
    Map.entry("k2", "v2"),
    // ... хоть 100 пар
    Map.entry("k100", "v100")
);

🚀 Когда использовать?

Идеально подходит для конфигураций, статических словарей, тестовых данных и справочников, которые не меняются во время работы программы.

#Java #CodeTips #Programming #Java9

👉 @java_geek

💿 Java Records: Конец эпохи Lombok?

Долгие годы Project Lombok был нашим единственным спасением от бесконечных геттеров, сеттеров, equals() и hashCode(). Но начиная с Java 14 (и официально в Java 16), в языке появилась нативная альтернатива - Records.

Многие поспешили удалить Lombok и переписать всё на рекорды. И... столкнулись с проблемами. Давайте разберем, почему record - это не просто "короткий класс".

🏎 Скорость написания

Lombok (@Value для неизменяемости):

@Value
public class User {
    String name;
    int age;
}

Record:

public record User(String name, int age) {}

Тут победа за рекордами. Синтаксис максимально лаконичен. Мы объявляем состояние, а не поля.

🔍 Что под капотом? (Главные отличия)

Вот здесь начинаются нюансы, из-за которых Records нельзя назвать полной заменой Lombok.

1. Жесткая неизменяемость (Immutability)
Record - это всегда final класс с final полями. Вы не можете сделать "сеттер" в рекорде. Если вам нужен изменяемый DTO (например, для заполнения формы по шагам) - Record не подойдет. Lombok @Data всё еще нужен.

2. Запрет на наследование
Рекорды не могут наследоваться от других классов (они уже неявно наследуются от java.lang.Record).

• Если у вас есть BaseEntity с полем ID - вы не сможете унаследовать рекорд от него.

3. Имена геттеров
Это ломает многие старые библиотеки.

• Lombok/JavaBean: getName(), getAge()
• Record: name(), age()
• Совет: Jackson и современные JSON-библиотеки уже умеют с этим работать, но легаси-фреймворки могут "не увидеть" ваши поля.

✨ Killer Feature: Компактные конструкторы

То, чего нет в Lombok. Валидация данных в рекордах выглядит потрясающе чисто. Вам не нужно дублировать аргументы:

public record User(String name, int age) {
    // Обратите внимание: нет скобок с аргументами!
    public User {
        if (age < 0) {
            throw new IllegalArgumentException("Age cannot be negative");
        }
        name = name.toUpperCase(); // Можно даже менять данные перед записью
    }
}

🏆 Вердикт: Кто победил?

Никто. Это инструменты для разных целей.

✅ Используйте record: Для DTO, ключей в Map, ответов API, записей в Event Log и промежуточных данных в Stream API. Это "именованные кортежи" данных.

✅ Используйте Lombok / POJO: Для JPA сущностей (Hibernate не очень любит рекорды из-за прокси и отсутствия сеттеров), для классов с наследованием и там, где нужна мутабельность.

#Java #Lombok #CleanCode #Java17

👉 @java_geek

🐳 Java Testing: Хватит мокать базы данных!

Вы всё еще используете H2 для тестов, а в продакшене стоит PostgreSQL? Или, может быть, вы поднимаете docker-compose руками перед запуском mvn test?


⛔ Как было раньше

Раньше нам приходилось делать трюки с @DynamicPropertySource, чтобы вручную прокинуть jdbc:url, username и password из поднятого контейнера в контекст Spring.

// Old School (Java 17 / Boot 2.7)
@DynamicPropertySource
static void registerPgProperties(DynamicPropertyRegistry registry) {
    registry.add("spring.datasource.url", postgres::getJdbcUrl);
    registry.add("spring.datasource.username", postgres::getUsername);
    // ... куча ручного кода
}

✅ Как сейчас

@ServiceConnection сама понимает, что это за контейнер (Postgres, Redis, Kafka, RabbitMQ), и автоматически прописывает нужные свойства в ваш application.properties на время теста.

@Testcontainers
@SpringBootTest
class OrderIntegrationTest {

    // 1. Объявляем контейнер
    @Container
    @ServiceConnection // 👈 Вся магия тут!
    static PostgreSQLContainer<?> postgres = 
        new PostgreSQLContainer<>("postgres:16-alpine");

    @Autowired
    private OrderRepository repository;

    @Test
    void shouldSaveOrder() {
        // 2. Тест работает с РЕАЛЬНОЙ базой в Docker
        var order = new Order("item-123", BigDecimal.TEN);
        repository.save(order);
        
        assertThat(repository.findAll()).hasSize(1);
    }
}

Писать контейнер в каждом тестовом классе - дурной тон (и медленно, так как Docker будет стартовать каждый раз заново).
В Spring Boot 3.1 появился паттерн TestConfiguration, который позволяет переиспользовать контейнеры.

Создаем один файл конфигурации:

@TestConfiguration(proxyBeanMethods = false)
public class ContainersConfig {

    @Bean
    @ServiceConnection
    public PostgreSQLContainer<?> postgresContainer() {
        return new PostgreSQLContainer<>("postgres:16-alpine");
    }

    @Bean
    @ServiceConnection
    public KafkaContainer kafkaContainer() {
        return new KafkaContainer(DockerImageName.parse("confluentinc/cp-kafka:7.4.0"));
    }
}

Теперь в любом тесте просто импортируем этот конфиг:

@Import(ContainersConfig.class)
@SpringBootTest
class AnyIntegrationTest { ... }

Вы можете использовать этот же конфиг, чтобы запустить само приложение локально с поднятыми контейнерами! Больше не нужно настраивать локальный Postgres.

В папке src/test/java создайте класс для запуска:

public class TestApplication {
    public static void main(String[] args) {
        SpringApplication.from(MyRealApplication::main)
            .with(ContainersConfig.class) // Подключаем наши контейнеры
            .run(args);
    }
}

Запускаете TestApplication -> Spring сам поднимает Docker-контейнеры -> приложение коннектится к ним -> вы работаете.

🏁 Итог

• Изоляция: Каждый прогон тестов - чистая среда.
• Честность: Тестируйте на том, что будет в продакшене.
• Удобство: @ServiceConnection убрал весь бойлерплейт.

#SpringTest #Testcontainers #Java #DevOps #Docker

👉 @java_geek

🗑️ Java Garbage Collector: Кто убирает за вами мусор?

Разработчики на C и C++ живут в постоянном страхе утечек памяти: выделил память через malloc - обязан очистить через free. Мы же в Java просто пишем new Object() и идем пить кофе.

Всю грязную работу делает Garbage Collector (Сборщик мусора или просто GC). Но если не понимать, как он работает, ваше приложение однажды просто "зависнет" на пару секунд на продакшене.

🛑 Главная проблема: Stop-The-World

GC не может убирать мусор, пока ваше приложение активно меняет ссылки на объекты. Ему нужно поставить всё на паузу. Эта пауза называется Stop-The-World (STW).
В этот момент все ваши потоки замирают, пользователи видят "колесико загрузки", а запросы по сети отваливаются по таймауту. Вся эволюция GC в Java - это борьба за уменьшение этих пауз.

🧬 Гипотеза поколений

Как GC понимает, что удалять? Он опирается на одно гениальное наблюдение: 98% объектов умирают молодыми. (Например, локальные переменные внутри метода живут доли секунды).

Поэтому память (Heap) поделили на две части:
1. Young Generation (Молодое поколение): Сюда попадают все новые объекты. Очистка здесь происходит часто и невероятно быстро (Minor GC).

2. Old Generation (Старое поколение): Сюда "переезжают" объекты-долгожители (например, закэшированные данные или синглтоны Spring). Очистка здесь происходит редко, но занимает много времени (Major/Full GC).



🥊 Битва титанов: Какой GC выбрать?

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

1. G1 (Garbage-First)
• Статус: Включен по умолчанию с Java 9.

• Как работает: Дробит память на сотни мелких регионов. Во время уборки он смотрит: "Ага, вот в этом регионе 90% мусора, начну с него" (отсюда и название - мусор в первую очередь).

• Кому подходит: 95% обычных веб-приложений. Он отлично балансирует между высокой пропускной способностью и приемлемыми паузами (целевая пауза по умолчанию — 200 мс).

2. ZGC (Z Garbage Collector)
• Статус: Готов к бою (Production Ready) с Java 15, а в Java 21 стал генерационным.

• Как работает: Настоящая магия и инженерное чудо. ZGC выполняет почти всю работу параллельно с вашим приложением, используя "цветные указатели" (colored pointers).

• Суперсила: Паузы Stop-The-World не превышают 1 миллисекунды, даже если у вас куча (Heap) размером в 16 Терабайт!

• Кому подходит: Финансовым биржам, игровым серверам и системам, где важна ультра-низкая задержка (Low Latency).

🛠 Как включить?

Ничего устанавливать не нужно, просто добавьте флаг при запуске java -jar:

• Для G1 (если у вас старая Java): -XX:+UseG1GC

• Для ZGC: -XX:+UseZGC

🧠 Золотое правило Memory Management
Сборщик мусора в Java невероятно умен. Не пытайтесь ему "помогать".
Вызовы System.gc() в коде - это выстрел себе в ногу. Просто пишите чистый код, не держите ссылки на объекты, которые вам больше не нужны, и GC сделает всё сам.

#Java #GarbageCollector #Performance #JVM #Backend

👉 @java_geek