Java Ready | Программирование

Почему String.format может заменить точку на запятую?

Представим, что программа сохраняет числовое значение в текстовый файл. Хочется получить 12.50, поэтому пишем:
String value = String.format("%.2f", 12.5);

Но результат без явной локали зависит от настроек среды, в которой запущена JVM. На одной машине это будет 12.50, на другой 12,50. Для интерфейса пользователя локальные правила полезны, а для машинного формата такой сюрприз может испортить импорт.

Разницу легко показать без изменения настроек компьютера:
String de = String.format(Locale.GERMANY, "%.2f", 12.5);

Здесь получится 12,50. Если строку должен читать другой сервис с точкой в качестве разделителя, укажите нейтральную локаль явно:
String stable = String.format(Locale.ROOT, "%.2f", 12.5);

Теперь получится 12.50 независимо от локали пользователя. Это важно для логов с фиксированным форматом.

Для текста, который читает человек, наоборот, можно передать нужную ему локаль:
String label = String.format(userLocale, "%.2f", 12.5);

Так отображение будет привычным для пользователя. Но если вы записываете структурированные данные, лучше использовать подходящий формат и библиотеку, например JSON-сериализатор, а не собирать документ через String.format.

👉 Java Ready | #совет

Почему split(".") в Java не делит строку по точке?

На первый взгляд кажется, что достаточно передать в split нужный символ:
String[] parts = "app.log".split(".");

Но split принимает регулярное выражение. Точка в regex означает любой символ, поэтому такой вызов не ищет буквальную точку между app и log.

Для настоящей точки её нужно экранировать в регулярном выражении. В Java-строке обратный слеш тоже экранируется, поэтому в исходнике получается два слеша:
String[] parts = "app.log".split("\\.");
System.out.println(Arrays.toString(parts));

Теперь результатом будут app и log.

Та же ловушка есть у других специальных символов regex. Например, вертикальная черта обозначает альтернативу. Когда разделитель приходит из переменной, удобнее не вспоминать все правила экранирования:
String separator = "|";
String[] fields = line.split(Pattern.quote(separator));

Pattern.quote превращает текст разделителя в буквальный шаблон. Если пользователь выберет точку, плюс или квадратную скобку, смысл разделения не изменится.

Есть ещё нюанс в конце строки. По умолчанию split убирает пустые элементы справа:
System.out.println(Arrays.toString("a,b,".split(",")));

Вы увидите только a и b. Если формат данных считает завершающее пустое поле значимым, передайте отрицательный limit:
String[] fields = "a,b,".split(",", -1);

Здесь будет три элемента, последний из них пустая строка.

👉 Java Ready | #совет

Безопасная настройка retry для всей системы!

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

Автор разбирает:
• какие ошибки имеет смысл повторять, а какие нет
• чем отличаются блокирующие и неблокирующие retry у Kafka consumer
• как повторы на нескольких уровнях создают лишнюю нагрузку

Продолжай читать на Habr!

👉 Java Ready | #статья

Почему после Stream.toList() нельзя добавить элемент?

При работе со Stream часто нужно собрать результаты обратно в список. Короткая запись выглядит естественно:
var names = Stream.of("Ana", "Bob").toList();

Но у Stream.toList() есть важное свойство, он возвращает немодифицируемый список. Такой код не добавит третье имя:
names.add("Cyd");

Вместо изменения списка программа получит UnsupportedOperationException. То же произойдёт при remove или set.

Если нужен готовый результат только для чтения, это как раз удобно:
List labels = users.stream()
.map(User::name)
.toList();

Вызывающий код не сможет случайно поменять состав labels. При этом сами элементы могут оставаться изменяемыми, не модифицируемость списка не делает глубоко неизменяемыми объекты внутри него.

Если список нужно дополнять после сбора, задайте изменяемую коллекцию явно:
var names = Stream.of("Ana", "Bob")
.collect(Collectors.toCollection(ArrayList::new));

Теперь add и remove доступны. Есть и вариант обернуть готовый результат:
var names = new ArrayList(stream.toList());

Выбирайте способ сбора по тому, что будет происходить со списком дальше. Для чтения подойдёт toList(), для дальнейших изменений лучше явно создать ArrayList.

👉 Java Ready | #совет

Находим три самых популярных товара!

Есть поток покупок с повторяющимися названиями. Построим небольшую сводку, которая считает частоты и показывает лидеров.

В этой задаче:

• собираем счётчики через Map.merge
• сортируем товары по частоте
• оставляем топ-3 и печатаем результат

Когда данных станет очень много, вместо полной сортировки можно оставить только три записи в маленькой куче.

👉 Java Ready | #задача

Шпаргалка по sealed-иерархиям в Java!

На картинке показано, как sealed-класс ограничивает прямых наследников. Одни ветки закрываются через final, другая остаётся контролируемой через sealed, а non-sealed снова разрешает свободное наследование.

Например, для фиксированного набора фигур можно явно перечислить допустимые реализации Shape. Это помогает выразить границы модели прямо в типах и облегчает проверку вариантов при работе с pattern matching.

Сохрани, чтобы не потерять!

👉 Java Ready | #ресурс

Почему kubectl apply ещё не означает, что приложение заработало?

Во время деплоя часто запускают одну команду и считают её успешное завершение концом работы:
kubectl apply -f deployment.yaml

Но apply сообщает, что Kubernetes принял описание ресурса. Новые Pod могут ещё создаваться, скачивать образ, ждать readiness probe или падать при запуске.

После apply проверьте именно завершение обновления Deployment:
kubectl rollout status deployment/app --timeout=120s

Команда ждёт завершения rollout и возвращает ошибку, если не дождалась его за указанное время. Название app здесь должно совпадать с именем вашего Deployment.

В скрипте команды удобно поставить рядом:
set -e
kubectl apply -f deployment.yaml
kubectl rollout status deployment/app --timeout=120s

Теперь пайплайн не продолжит работу после неуспешного ожидания. Само по себе это всё ещё не заменяет проверку приложения снаружи кластера. Сервис, ingress и внешние зависимости могут ломаться отдельно.

Если обновление застряло, сначала посмотрите состояние ресурсов:
kubectl get deployment app
kubectl get pods -l app=app

Затем откройте события Deployment и причину проблемы у конкретного Pod:
kubectl describe deployment app
kubectl describe pod POD_NAME

Проблемой может оказаться неверный образ, недоступный секрет, ошибка readiness probe или нехватка ресурсов.

Предыдущую ревизию можно вернуть отдельно:
kubectl rollout undo deployment/app

После отката тоже проверьте rollout status.

➡️ DevOps Ready | #совет

Собираем Tower Defense с JavaFX и FXGL!

Автор решил попробовать FXGL на проекте и начал с игры, в которой враги идут по маршруту, а игрок расставляет башни. Получился не только экран с графикой, но и небольшой игровой цикл с ресурсами, волнами и улучшениями.

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

Продолжай читать на Habr

👉 Java Ready | #статья

Почему trim() может не убрать пробелы по краям строки?

В Java часто очищают пользовательский ввод так:
String name = input.trim();

Но trim() ориентируется на символы с кодом не выше U+0020. Некоторые пробельные символы Unicode под это правило не попадают.

Например, строка может начинаться и заканчиваться широким пробелом U+2003:
String input = "\u2003admin\u2003";
System.out.println(input.trim().length());

Видимые на экране отступы останутся. Это может сломать сравнение логина, поиск ключа или проверку поля формы.

Начиная с Java 11 есть strip(), который опирается на определение пробельного символа в Character.isWhitespace:
String name = input.strip();
System.out.println(name.equals("admin"));

Если нужна очистка только с одной стороны, есть отдельные методы:
String left = input.stripLeading();
String right = input.stripTrailing();

Для проверки строки, состоящей только из пробелов, пригодится isBlank():
if (input.isBlank()) {
throw new IllegalArgumentException("Empty name");
}

strip() не удаляет все символы, которые выглядят как пробелы. Для специальных форматов ввода полезно отдельно определить допустимые символы.

👉 Java Ready | #совет

Ищем одинаковые файлы на Java!

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

В этой задаче:

• обходим вложенные папки
• считаем SHA-256 потоково
• группируем пути по хешу
• показываем кандидатов на дубликаты

Результат поможет разобрать архивы, папки и копии.

👉 Java Ready | #задача

Напоминалка по устройству Java records!

На картинке показано, из каких частей состоит record и что генерирует компилятор.

Например, запись public record Person(String name, int age) создаёт final-поля, канонический конструктор, методы name(), age(), equals() и hashCode() без ручного шаблонного кода.

Сохрани, чтобы не потерять!

👉 Java Ready | #совет

Почему Files.lines() нельзя оставлять без try-with-resources?

Files.lines() выглядит как удобный способ быстро получить Stream строк из файла. Но за этим Stream остаётся открытый файловый ресурс.
Stream lines = Files.lines(path);
long count = lines.count();

После count поток может быть исчерпан, но файл не обязан закрыться сразу. В долгоживущем сервисе или цикле обработки это приводит к накоплению открытых дескрипторов.

Правильнее ограничить жизнь Stream блоком try-with-resources.
try (Stream lines = Files.lines(path)) {
long count = lines.count();
}

Java закроет поток даже при исключении внутри обработки. Это особенно полезно для больших логов, CSV-файлов и пакетных задач, где не хочется загружать всё содержимое в память.

Если нужен небольшой файл целиком, можно взять готовый список строк.
List lines = Files.readAllLines(path);

readAllLines проще, но читает файл полностью. Files.lines подходит для потоковой обработки, если не забывать закрывать ресурс.

👉 Java Ready | #совет

Java 25 становится проще!

Автор разбирает JEP-512 и изменения, которые позволяют писать небольшие программы с меньшим количеством обязательной обвязки. Вместо класса, static main и ручных импортов можно сосредоточиться на самой задаче, а не на стартовом шаблоне.

В статье разбирают:
• как устроены упрощённые исходники Java 25
• зачем появились неявные импорты и класс IO
• как запускать короткие Java-скрипты из командной строки

Продолжай читать на Habr

👉 Java Ready | #статья