Java

Критическая уязвимость в Java: атака по сети без пароля и участия пользователя

Oracle опубликовала предупреждение CVE-2026-91403 с оценкой CVSS 9.1. Проблема находится в JSSE — компоненте Java, который обеспечивает защищённые соединения TLS.

По описанию Oracle, успешная атака может позволить читать, изменять и удалять данные, доступные уязвимому приложению. Для эксплуатации не нужны учётные данные, а сложность атаки оценена как низкая.

В списке затронутых версий:

- Java SE 8u511 / 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 и 27.0.1.
- Oracle GraalVM for JDK 17.0.21 и 21.0.13.
- Oracle GraalVM Enterprise Edition 21.3.20.

Условия зависят от приложения: Oracle указывает на сценарии, где данные атакующего попадают в API уязвимого компонента, например через веб-сервис. Само наличие Java ещё не означает, что любой сервис можно атаковать.

Администраторам стоит проверить используемые сборки Java, включая runtime внутри контейнеров, и установить исправления по инструкции поставщика.

Предупреждение опубликовано 21 октября. Более ранние версии тоже могут быть затронуты — отсутствие в списке не подтверждает их безопасность.

https://www.oracle.com/security-alerts/alert-cve-2026-91403.html

Java: почему месяц `5` может оказаться июнем

В Calendar месяцы нумеруются с нуля: январь 0, май 4, июнь 5. Простая ловушка, которая легко превращается в баг.

Начиная с Java 8, для нового кода выбирайте java.time:
LocalDate date = LocalDate.of(2026, 5, 31);
LocalDate deadline = date.plusDays(7);

String text = deadline.format(
    DateTimeFormatter.ISO_LOCAL_DATE
);
// 2026-06-07
Здесь 5 означает май, а plusDays() возвращает новый объект, сохраняя исходную дату. Основные типы java.time неизменяемы и безопасны для совместного использования потоками.

Помните: `LocalDateTime` не содержит часового пояса. Для однозначного момента события используйте Instant или задавайте пояс явно.

Spring Boot 4 убрал статус WILL_EXPIRE_SOON: проверьте мониторинг сертификатов

В Spring Boot 3 SSL-компонент health endpoint переходил в особый статус WILL_EXPIRE_SOON, если сертификат скоро истекал. Для проб Kubernetes и балансировщиков это было неудобно: непонятно, считать сервис живым или нет.

В Spring Boot 4 этот статус убрали. Health остаётся UP, а цепочки сертификатов, срок которых скоро закончится, перечисляются в details.expiringChains. Порог предупреждения задаётся свойством management.health.ssl.certificate-validity-warning-threshold:
management:
  health:
    ssl:
      certificate-validity-warning-threshold: 14d
  endpoint:
    health:
      show-details: always
Ответ /actuator/health тогда выглядит так:
{
  "status": "UP",
  "details": {
    "expiringChains": ["server-cert…"]
  }
}
Практический вывод простой: пробы больше не будут дёргаться из-за истекающего сертификата, но и алерт по смене статуса тоже не сработает. Если мониторинг ловил WILL_EXPIRE_SOON, переключите его на проверку непустого expiringChains и не забудьте включить show-details, иначе деталей в ответе не будет.

💡 Java: переопределяешь equals() - переопредели и hashCode()
Два объекта с одинаковым email могут быть равны по equals(), но HashSet.contains() при этом вернёт false.
Причина: HashSet и HashMap сначала используют хеш, чтобы определить, где искать объект, а затем проверяют равенство. Если хеши различаются, до equals() дело может не дойти.
Правило: равные объекты обязаны иметь одинаковый hashCode(). При этом одинаковый хеш не гарантирует равенство - коллизии допустимы.
В примере на картинке равенство определяется по email, поэтому хеш тоже вычисляется по нему.
И ещё: не меняйте поля, участвующие в equals() и hashCode(), пока объект хранится в HashSet или используется как ключ HashMap - поиск может перестать его находить.
#Java #OOP

💡 Java: не используй `Thread.sleep()` для ожидания работы

Thread.sleep() - это просто пауза на заданное время.

Проблема в том, что ты угадываешь:

❌ поток может проснуться слишком рано  
❌ или наоборот, ждать дольше, чем нужно  
❌ polling через sleep() создаёт лишние задержки и проверки

Для координации потоков лучше использовать:

✅ wait() / notify()  
✅ CountDownLatch  
✅ другие примитивы синхронизации из java.util.concurrent

Например:
CountDownLatch done = new CountDownLatch(1);

done.await();      // ждём сигнал
done.countDown();  // работа завершена
А если задача должна выполняться периодически, вместо бесконечного цикла с sleep() лучше взять
ScheduledExecutorService exec =
    Executors.newSingleThreadScheduledExecutor();

exec.scheduleAtFixedRate(
    this::doWork,
    0,
    1,
    TimeUnit.SECONDS
);

Thread.sleep() хорошо подходит для простой задержки.
Для ожидания события и периодических задач в Java есть более точные инструменты.

#Java #Concurrency

типов из других модулей

В Spring Boot 4 появилась полезная штука для конфигурации больших проектов.

@ConfigurationPropertiesSource позволяет генерировать metadata для типов, которые находятся не в текущем модуле, а, например, в общей библиотеке или отдельном starter-модуле.

Раньше с такими внешними типами IDE-подсказки для application.yml и application.properties
могли быть неполными или вообще отсутствовать.

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

Особенно полезно для:

— multi-module проектов
— внутренних Spring Boot starter'ов
— shared configuration libraries
— больших платформенных команд

Мелкая фича, но для DX в крупных Spring Boot проектах очень приятная.

#SpringBoot4 #Config

💡 **Когда `ReentrantReadWriteLock` быстрее обычного `synchronized`**

Если приложение часто читает данные и редко их изменяет, один эксклюзивный lock может стать узким местом.

`ReentrantReadWriteLock` разделяет блокировки:

- несколько потоков могут одновременно держать `readLock`;
- `writeLock` получает исключительный доступ;
- во время записи блокируются и читатели, и другие писатели.

```java
private final ReentrantReadWriteLock lock =
new ReentrantReadWriteLock();

private final Lock readLock = lock.readLock();
private final Lock writeLock = lock.writeLock();

public String get(String key) {
readLock.lock();
try {
return cache.get(key);
} finally {
readLock.unlock();
}
}

public void put(String key, String value) {
writeLock.lock();
try {
cache.put(key, value);
} finally {
writeLock.unlock();
}
}
```

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

Однако `ReentrantReadWriteLock` подходит не всегда. При коротких операциях, высокой конкуренции между писателями или частых обновлениях накладные расходы могут оказаться выше, чем у обычного `synchronized` или `ReentrantLock`.

Используйте его для read-heavy сценариев и обязательно проверяйте результат под реальной нагрузкой.

💡 Не используйте `Stream.peek()` для бизнес-логики

peek() предназначен в первую очередь для отладки: он выполняет побочное действие внутри цепочки и зависит от терминальной операции.
users.stream
()
    .peek(System.out::println)
    .toList();
Для реальной обработки выбирайте:

* map() — преобразовать элементы;
* filter() — отфильтровать;
* forEach() — явно выполнить действие.

Код со скрытыми побочными эффектами сложнее читать, тестировать и поддерживать.

#Java #Streams

10 дистрибутивов Linux - 10 боевых стилей. Пейн разбирает, кому что подойдёт: от Ubuntu новичкам до Arch для тех, кто любит контроль. Выбор зависит от задачи, а не от хайпа

#linux #ubuntu #arch #наруто

🚀 HTTP-клиенты в Spring Boot через @HttpExchange

Описываете внешний API обычным Java-интерфейсом:

@HttpExchange("https://api.example.com")
public interface UserClient {

@GetExchange("/users/{id}")
User findById(@PathVariable Long id);

@PostExchange("/users")
User create(@RequestBody User user);
}

Spring сам создаёт реализацию клиента, после чего его можно внедрять как обычный bean.

Таймауты, SSL и другие параметры настраиваются через spring.http.clients.*.

Меньше шаблонного кода, понятный контракт и удобное тестирование.

#SpringBoot4 #Java #HttpExchange