Какие проблемы языка Java или стандартных библиотек наиболее критичны?

Что проверяют

Насколько глубоко вы знаете язык: можете ли назвать реальные слабые места, объяснить, чем они опасны, и знаете ли, что уже исправлено в современных версиях. Следом обычно просят пример, где такая проблема укусила вас в проекте.

Как отвечать

Возьмите три или четыре пункта и к каждому дайте обход:

• null: любая ссылка может оказаться null, система типов этого не выражает. Обход: Optional для возвращаемых значений, аннотации JSpecify с проверкой NullAway, Objects.requireNonNull на границах;
• стирание типов: в рантайме List<String> и List<Integer> неразличимы, new T[] не написать, а List<int> невозможен. Отсюда автоупаковка и ловушка с == для Integer: кеш значений от -128 до 127 делает сравнение ссылок то верным, то нет;
• старые API дат: Date и Calendar изменяемые, месяцы в них с нуля, SimpleDateFormat не потокобезопасен. Замена: java.time с Java 8;
• checked-исключения: плохо сочетаются с лямбдами и стримами, их заворачивают в RuntimeException;
• коллекции: Collections.unmodifiableList это только представление, исходный список меняется под ним. Arrays.asList фиксированного размера, List.of неизменяем и падает на null;
• сериализация: встроенная десериализация чужих данных остаётся источником уязвимостей;
• BigDecimal.equals: учитывает масштаб, 1.0 и 1.00 не равны, сравнивать нужно через compareTo.

Покажите и то, что уже закрыто: многословность смягчили record, var и pattern matching, а виртуальные потоки из Java 21 с Java 24 больше не прилипают к платформенному потоку внутри synchronized.

Где спотыкаются

Называют паузы сборщика мусора проблемой языка. Это свойство рантайма, и оно настраивается: G1 работает по умолчанию, для низких задержек есть ZGC.

Смешивают язык с безопасностью приложения. SQL-инъекция не проблема Java: PreparedStatement в JDBC есть с первых версий.

Только жалуются, без обходов и без понимания, что из списка уже исправлено. Ответ тогда звучит как устаревший конспект.