Какие ошибки делают разработчики, переходящие на Java с другого языка или стека?

Ошибка 1: Optional как замена null вместо API-контракта

Разработчики из Python или JavaScript привыкают проверять null везде. В Java Optional предназначен для возвращаемых значений API, а не для полей класса или параметров методов. Типичная ошибка:

// Неверно: Optional в поле — сериализация сломается, equals/hashCode сложнее
public class User {
    private Optional<String> middleName; // плохо
}

// Верно: Optional только в сигнатуре метода
public Optional<User> findById(long id) {
    return userRepository.findById(id); // возвращает Optional
}

// Вызов без .get() — используем map/orElse
String name = findById(42)
    .map(User::getFullName)
    .orElse("Unknown");

Ошибка 2: Игнорирование checked exceptions

Разработчики из Python или Go не привыкли к checked exceptions. Частое решение — обернуть всё в RuntimeException и забыть. Это ломает обработку ошибок на уровне выше:

// Плохо: проглатываем исключение
try {
    Files.readAllBytes(path);
} catch (IOException e) {
    // пусто или e.printStackTrace()
}

// Хорошо: либо пробрасываем с контекстом, либо транслируем
try {
    return Files.readAllBytes(path);
} catch (IOException e) {
    throw new FileProcessingException("Cannot read config: " + path, e);
}

Ошибка 3: Мутабельные объекты в коллекциях

После Python-словарей или JavaScript-объектов разработчики забывают, что Java-коллекции хранят ссылки. Изменение объекта после помещения в HashSet ломает инвариант:

Set<Point> set = new HashSet<>();
Point p = new Point(1, 2);
set.add(p);
p.setX(99); // hashCode изменился — объект «потерян» в Set
System.out.println(set.contains(p)); // false!

// Решение: использовать record (Java 16+) — immutable by design
record Point(int x, int y) {} // equals/hashCode автоматические и финальные

Ошибка 4: Блокирующий I/O в реактивном контексте

Разработчики, переходящие с синхронного Python на Spring WebFlux или Project Reactor, вызывают блокирующие операции внутри реактивной цепочки. Это блокирует Netty event loop:

// Неверно: JDBC — блокирующий, нельзя внутри Mono/Flux
Mono.fromCallable(() -> jdbcTemplate.queryForObject(sql, Long.class))
    // ^ исполняется в event loop — deadlock или деградация

// Верно: переключаемся на boundedElastic-шедулер для блокирующего кода
Mono.fromCallable(() -> jdbcTemplate.queryForObject(sql, Long.class))
    .subscribeOn(Schedulers.boundedElastic());

Ошибка 5: String конкатенация в цикле

В Python строки тоже immutable, но разработчики не всегда понимают накладные расходы в Java. Конкатенация через + создаёт O(n²) мусора:

// Плохо: каждая итерация создаёт новый String
String result = "";
for (String item : items) {
    result += item + ", "; // N копий строки
}

// Хорошо: StringBuilder или String.join
String result = String.join(", ", items);
// Или для сложной логики:
StringBuilder sb = new StringBuilder();
for (String item : items) {
    sb.append(item).append(", ");
}

Ошибка 6: Игнорирование equals/hashCode при использовании Lombok

@Data от Lombok генерирует equals/hashCode по всем полям. Если сущность JPA входит в коллекцию до сохранения (id == null), а после сохранения id присваивается, hashCode меняется и объект теряется в Set. Правильно: генерировать equals/hashCode только по id или использовать @EqualsAndHashCode(onlyExplicitlyIncluded = true).

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

• ClassLoader leaks в web-контейнерах (Tomcat): статические поля, удерживающие ссылки на ClassLoader, приводят к OutOfMemoryError при hot-reload.
• ThreadLocal в пуле потоков Spring: RequestContextHolder и SecurityContextHolder используют ThreadLocal — при переключении на Virtual Threads нужно проверить совместимость.
• Primitive vs Boxed types: автоупаковка в горячих путях создаёт GC-давление. Используйте int[] вместо List<Integer> для числовых массивов.
• try-with-resources забывают для собственных AutoCloseable: утечки соединений в пулах JDBC или файловых дескрипторов.
• Перенос async/await из C# в CompletableFuture: цепочка .thenCompose/.thenApply непривычна и легко приводит к race conditions без явной синхронизации.
• Reflection в production: частое использование getDeclaredField/setAccessible в горячем пути снижает производительность на 10–100x по сравнению с прямым доступом.
• Сравнение enum через equals вместо ==: для enum оба работают, но == быстрее и явно передаёт намерение.
• Игнорирование finalize(): объекты с finalize() обрабатываются GC медленнее — используйте Cleaner API (Java 9+).

• Перечислять ошибки без объяснения причин
• Не отличать beginner mistakes от production failure modes
• Не предлагать процесс, который предотвращает повторение ошибок

• Знает типичные ошибки при работе с Java
• Понимает причины ошибок
• Предлагает практики prevention и early detection