Включить reflection-free Jackson в Quarkus — легко. Настоящая работа начинается с того, чтобы понять, сохраняется ли ваш JSON-контракт.

Автор собрал небольшой API каталога с DTO на record-классах, обобщённым Page<T>, полиморфными payload-ами, кастомным сериализатором и контрактными тестами: baseline против reflection-free режима.

#java #quarkus

👉 Java Portal

Выражения switch в Java 14+ являются исчерпывающими (exhaustive): компилятор проверяет, что обработаны все возможные значения.

✅ Если пропустить константу enum, компиляция завершится ошибкой
✅ Исправить это можно, обработав все значения enum или добавив ветку default
✅ Более безопасный рефакторинг и меньше скрытых ошибок
#Java #JavaDev

👉 Java Portal

💡 Java: Удаляйте неиспользуемые импорты и переменные для повышения читаемости кода.

Лишние импорты и неиспользуемые переменные создают визуальный шум, усложняют навигацию по коду и затрудняют поддержку. Большинство IDE умеют автоматически находить и удалять такой код.

#Java #CleanCode

👉 Java Portal

💡 Java: Используйте default-методы в интерфейсах для сохранения обратной совместимости (начиная с Java 8).

Если добавить новый default-метод в интерфейс, существующие реализации не придётся менять. Они автоматически получат реализацию по умолчанию.

#Java #Interfaces

👉 Java Portal

Java: По возможности не возвращайте из методов изменяемые внутренние коллекции, чтобы:
Не раскрывать внутреннее состояние объекта, повышая безопасность.
Иметь возможность менять реализацию без риска сломать другие части приложения.

#Java #JavaDev

👉 Java Portal

Java: Используйте блоки try-catch только там, где это действительно необходимо. Не применяйте исключения для управления логикой выполнения программы. #Java #BestPractices

👉 Java Portal

Java: Не делай поля публичными. Держи их private и используй геттеры/сеттеры для инкапсуляции. #Java #OOP

👉 Java Portal

💡 Java: Ловите ошибки ещё на этапе компиляции, помечая переопределённые методы аннотацией @Override. #Java #Annotations

// ❌ Опечатка в имени метода — код компилируется,
// но вы НЕ переопределили toString()

public class User {
    private final String name;

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

    public String toStrng() { // хотели toString()
        return name;
    }
}

// Баг остаётся незамеченным — println(user)
// не будет использовать ваш метод



// ✅ @Override превращает опечатку в ошибку компиляции

public class User {
    private final String name;

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

    @Override
    public String toString() {
        return "User(" + name + ")";
    }
}

// @Override
// public String toStrng() { ... }
//
// Ошибка компиляции:
// method does not override or implement a method from a supertype

👉 Java Portal

💡 Совет по Java: всегда закрывайте ресурсы вроде BufferedReader, InputStream и OutputStream через try-with-resources, чтобы избежать утечек памяти и ресурсов. #Java #BestPractices

👉 Java Portal

Java: используйте полиморфизм вместо цепочек instanceof.
Проверки типов часто приводят к разрастающимся if/else, нарушают принцип Open/Closed и заставляют изменять существующий код при добавлении новых сущностей.

❌ До:

public String describe(Animal animal) {
    if (animal instanceof Dog) {
        return "Woof";
    } else if (animal instanceof Cat) {
        return "Meow";
    } else if (animal instanceof Cow) {
        return "Moo";
    }

    throw new IllegalArgumentException("Unknown animal");
}

Каждый новый тип требует правки метода.

✅ После:

public interface Animal {
    String sound();
}

public final class Dog implements Animal {
    public String sound() {
        return "Woof";
    }
}

public final class Cat implements Animal {
    public String sound() {
        return "Meow";
    }
}

public final class Cow implements Animal {
    public String sound() {
        return "Moo";
    }
}

public String describe(Animal animal) {
    return animal.sound();
}

Преимущества:
→ нет цепочек instanceof и приведения типов
→ меньше условной логики
→ проще расширять систему новыми типами
→ соблюдается принцип Open/Closed
→ поведение находится внутри самого объекта, а не размазано по коду

Добавить новое животное теперь можно без изменения существующей логики:

public final class Sheep implements Animal {
    public String sound() {
        return "Baa";
    }
}

Клиентский код останется прежним:

describe(new Sheep());

Пусть объекты сами решают, как себя вести. Именно для этого и существует полиморфизм. #Java #OOP

👉 Java Portal

Java Tip: Не перегружайте методы параметрами

Если метод принимает слишком много аргументов, возрастает риск передать значения в неправильном порядке, а код становится сложнее читать и поддерживать.

❌ Плохо:

createUser(firstName, lastName, street, city, zip, country);

✅ Лучше сгруппировать связанные данные в отдельный объект:

createUser(firstName, lastName,
    new Address(street, city, zip, country));

Такой подход:
• делает сигнатуры методов компактнее
• упрощает расширение модели данных
• снижает вероятность ошибок при вызове
• делает код более понятным и самодокументируемым

Если несколько параметров всегда используются вместе — вероятно, им нужен собственный класс или record.
#Java #Refactoring #CleanCode

👉 Java Portal

Java: Глубокие цепочки вроде user → address → city — классическая ловушка для NullPointerException. Вложенные проверки if (x != null) быстро разрастаются, и легко пропустить один из уровней.

✅Optional:

findByEmail(email)
    .map(User::getAddress)
    .map(Address::getCity)
    .orElse("unknown");

Если Optional в API нет, достаточно одной проверки:

if (user == null || user.getAddress() == null)

Такой подход читается лучше, чем множество разбросанных null-проверок, из-за которых сложно понять, какое именно значение может отсутствовать.
#Java #NullSafety

👉 Java Portal