Java: начиная с Java 14 можно использовать records для создания коротких неизменяемых объектов, предназначенных для хранения данных.
✅ короче обычных POJO
✅ имеют встроенные
✅ по умолчанию неизменяемые
#JavaDev #Records
👉 Java Portal
equals(), hashCode(), toString()#JavaDev #Records
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
JetBrains использует IDE-нативные возможности понимания кода, чтобы делать ИИ-агентов эффективнее на больших кодовых базах.
Зачем тратить время и токены на
Интересный момент: Codex, судя по наблюдениям, заметно лучше использует такие инструменты, чем Claude Code.
👉 Java Portal
Зачем тратить время и токены на
grep, если в IDE уже есть семантический поиск, навигация по символам и рефакторинги?Интересный момент: Codex, судя по наблюдениям, заметно лучше использует такие инструменты, чем Claude Code.
Please open Telegram to view this post
VIEW IN TELEGRAM
The JetBrains Blog
We Gave Agents IDE-Native Search Tools. They Got Faster and Cheaper. | The JetBrains AI Blog
We ran the same coding tasks with and without prebundled tooling, across multiple models and languages. Here's what changed.
👍3
Совет по Java
Используйте осмысленные имена методов, которые отражают их назначение.
#JavaDev #CleanCode
👉 Java Portal
Используйте осмысленные имена методов, которые отражают их назначение.
#JavaDev #CleanCode
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
POST не идемпотентен.
PUT — идемпотентен.
PATCH — зависит от реализации.
Ошибка в этих свойствах ломает ретраи.
Идемпотентность означает: один и тот же запрос даёт один и тот же результат.
Это важно, потому что сеть нестабильна, а клиенты делают повторные запросы.
Неидемпотентные эндпоинты дублируют побочные эффекты.
Два запроса могут означать две оплаты или два заказа.
GET — идемпотентен.
PUT — идемпотентен.
DELETE — идемпотентен.
POST — не идемпотентен.
PATCH — зависит (инкремент vs установка значения).
Для неидемпотентных эндпоинтов используют идемпотентные ключи:
клиент отправляет уникальный ключ,
сервер сохраняет ключ и ответ,
повтор с тем же ключом возвращает тот же результат.
Так устроены платёжные системы.
Без этого ретраи превращаются в дублирование операций.
👉 Java Portal
PUT — идемпотентен.
PATCH — зависит от реализации.
Ошибка в этих свойствах ломает ретраи.
Идемпотентность означает: один и тот же запрос даёт один и тот же результат.
Это важно, потому что сеть нестабильна, а клиенты делают повторные запросы.
Неидемпотентные эндпоинты дублируют побочные эффекты.
Два запроса могут означать две оплаты или два заказа.
GET — идемпотентен.
PUT — идемпотентен.
DELETE — идемпотентен.
POST — не идемпотентен.
PATCH — зависит (инкремент vs установка значения).
Для неидемпотентных эндпоинтов используют идемпотентные ключи:
клиент отправляет уникальный ключ,
сервер сохраняет ключ и ответ,
повтор с тем же ключом возвращает тот же результат.
Так устроены платёжные системы.
Без этого ретраи превращаются в дублирование операций.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥2
Возможно, один из самых безумных репозиториев с Docker
Он позволяет запускать полноценную macOS внутри Docker -контейнера и открывать её прямо из браузера.
- Поднимается macOS одной командой Докера
- Запуск полноценной macOS на Linux через QEMU/KVM
- Открывается сразу в браузере
- Поддержка нескольких версий macOS
- Подходит для тестирования, CI и macOS-специфичных инструментов
Такие проекты хорошо показывают, насколько далеко можно зайти с Docker и виртуализацией.
Репозиторий: https://github.com/dockur/macos
👉 Java Portal
Он позволяет запускать полноценную macOS внутри Docker -контейнера и открывать её прямо из браузера.
- Поднимается macOS одной командой Докера
- Запуск полноценной macOS на Linux через QEMU/KVM
- Открывается сразу в браузере
- Поддержка нескольких версий macOS
- Подходит для тестирования, CI и macOS-специфичных инструментов
Такие проекты хорошо показывают, насколько далеко можно зайти с Docker и виртуализацией.
Репозиторий: https://github.com/dockur/macos
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - dockur/macos: MacOS inside a Docker container.
MacOS inside a Docker container. Contribute to dockur/macos development by creating an account on GitHub.
👍3
Spring Boot: используйте
#SpringBoot #SoftwareDevelopment
👉 Java Portal
@Async только для небольших задач на оффлоадинг и только с явно заданным исполнителем.#SpringBoot #SoftwareDevelopment
Please open Telegram to view this post
VIEW IN TELEGRAM
Микросервисы — плохой выбор по умолчанию для 94% команд.
Зачем разбивать приложение на набор сервисов, которым нужно общаться через сеть.
На бумаге это выглядит как «правильный» подход. Масштабирование звучит привлекательно.
Но на практике я видел, как это ломается, шесть раз.
Команды из 5 инженеров поднимали 11 сервисов с несколькими очередями сообщений. Всё становилось медленнее.
Деплой, который занимал минуты, растягивался до 35 минут из-за зависимостей.
Отладка превращалась в кошмар: один баг — и приходится трейсить запрос через несколько сервисов и кодовых баз.
Сложность не уменьшилась. Она просто распределилась.
Микросервисы — это решение под масштабирование, но большинство команд внедряют их слишком рано, когда проблемы масштаба ещё нет.
Если ты всё ещё работаешь на localhost, основная проблема — не масштаб. Это стабильный релиз.
Когда микросервисы имеют смысл:
- команды блокируют работу друг друга
- части системы требуют независимого масштабирования
- есть нормальная трассировка в проде, и можно отлаживать без угадывания
Если этого нет — платишь налог распределённых систем без реальной выгоды.
Начинай с монолита и держи модульность. Делить стоит только тогда, когда связность начинает тормозить разработку.
Большинство обсуждений «нам нужны микросервисы» на деле не про архитектуру.
Они про грязную кодовую базу или болезненные деплои.
Сначала решаются эти проблемы.
Простые системы легче понимать. Перегруженные обычно разваливаются под собственным весом.
👉 Java Portal
Зачем разбивать приложение на набор сервисов, которым нужно общаться через сеть.
На бумаге это выглядит как «правильный» подход. Масштабирование звучит привлекательно.
Но на практике я видел, как это ломается, шесть раз.
Команды из 5 инженеров поднимали 11 сервисов с несколькими очередями сообщений. Всё становилось медленнее.
Деплой, который занимал минуты, растягивался до 35 минут из-за зависимостей.
Отладка превращалась в кошмар: один баг — и приходится трейсить запрос через несколько сервисов и кодовых баз.
Сложность не уменьшилась. Она просто распределилась.
Микросервисы — это решение под масштабирование, но большинство команд внедряют их слишком рано, когда проблемы масштаба ещё нет.
Если ты всё ещё работаешь на localhost, основная проблема — не масштаб. Это стабильный релиз.
Когда микросервисы имеют смысл:
- команды блокируют работу друг друга
- части системы требуют независимого масштабирования
- есть нормальная трассировка в проде, и можно отлаживать без угадывания
Если этого нет — платишь налог распределённых систем без реальной выгоды.
Начинай с монолита и держи модульность. Делить стоит только тогда, когда связность начинает тормозить разработку.
Большинство обсуждений «нам нужны микросервисы» на деле не про архитектуру.
Они про грязную кодовую базу или болезненные деплои.
Сначала решаются эти проблемы.
Простые системы легче понимать. Перегруженные обычно разваливаются под собственным весом.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Spring Boot: с
#SpringBoot #Hibernate
👉 Java Portal
org.hibernate.SQL=DEBUG можно получить более детальный вывод Hibernate-запросов прямо в логах.#SpringBoot #Hibernate
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
image_2026-05-10_08-18-07.png
50.9 KB
Завершаемые фьючеры для чистого асинхронного программирования
Устал от вложенных колбэков и шаблонного кода службы исполнения потоков. Встроенный механизм асинхронных вычислений в стандартной библиотеке версии 8 позволяет строить читаемые цепочки обработки задач без лишнего обвязочного кода.
Реальный сценарий: параллельные HTTP-вызовы к нескольким API с последующим объединением результатов, цепочкой преобразований и централизованной обработкой ошибок.
👉 Java Portal
Устал от вложенных колбэков и шаблонного кода службы исполнения потоков. Встроенный механизм асинхронных вычислений в стандартной библиотеке версии 8 позволяет строить читаемые цепочки обработки задач без лишнего обвязочного кода.
Реальный сценарий: параллельные HTTP-вызовы к нескольким API с последующим объединением результатов, цепочкой преобразований и централизованной обработкой ошибок.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Концепции Spring Security: OAuth2 Resource Server
С одной декларацией
1- Извлекать заголовок
2- Валидировать подпись токена через публичный ключ Authorization Server’а (полученный через JWKS URI)
3 Проверять claims: срок действия (
4- Заполнять
👉 Java Portal
С одной декларацией
OAuth2ResourceServer Spring Security будет:1- Извлекать заголовок
Authorization: Bearer <token> из каждого запроса2- Валидировать подпись токена через публичный ключ Authorization Server’а (полученный через JWKS URI)
3 Проверять claims: срок действия (
exp), issuer и audience4- Заполнять
SecurityContext аутентифицированным principal’омPlease open Telegram to view this post
VIEW IN TELEGRAM
❤6🌚2
Spring Boot: используй
#SpringBoot #SoftwareEngineering
👉 Java Portal
@EntityGraph для управления стратегиями загрузки и предотвращения N+1 запросов.#SpringBoot #SoftwareEngineering
Please open Telegram to view this post
VIEW IN TELEGRAM
🏆1
@Sql или @SqlGroup позволяют заранее загружать тестовые данные для выполнения воспроизводимых тестов.Позволяет:
#SpringBoot #IntegrationTesting
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
@ConditionalOnClass — это аннотация Spring Boot, которая используется в auto-configuration.#SpringBoot #Microservices
Please open Telegram to view this post
VIEW IN TELEGRAM
Новое в Java 25: гибкие тела конструкторов (
Теперь можно выполнять валидацию аргументов или подготовительную инициализацию до явного вызова другого конструктора (
👉 Java Portal
Flexible Constructor Bodies, JEP 513)!Теперь можно выполнять валидацию аргументов или подготовительную инициализацию до явного вызова другого конструктора (
this(...) или super(...)) — больше не нужны шаблонные вспомогательные методы (helper methods) ради такой логики.Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
В новых приложениях на Spring Boot у тебя есть выбор использовать WebClient вместо RestTemplate.
Он реактивный и неблокирующий
Работает на основе event loop, а не модели «один поток на один запрос» (
#SpringBoot #JavaDev
👉 Java Portal
Он реактивный и неблокирующий
Работает на основе event loop, а не модели «один поток на один запрос» (
thread-per-request)#SpringBoot #JavaDev
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Этот класс задуман как неизменяемый (immutable), но в нём есть неочевидный баг. Сможешь его найти?
👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔14👍6
Инструмент визуализации кода, который поможет разобраться в кодовой базе.
Поможет быстрее понять сложные проекты, разложив всё в понятной инфографике
⛓ Ознакомиться: Тык
👉 Java Portal
Поможет быстрее понять сложные проекты, разложив всё в понятной инфографике
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
У Java Streams не было необходимости в отдельном методе под каждый возможный use case.
Им была нужна точка расширения.
Stream Gatherers дают тебе встроенные gatherer’ы для типичных stateful-операций, а также возможность определять собственные intermediate-операции, оставаясь внутри Stream pipeline.
Ниже простой пример батчинга фиксированного размера через
Требуется Java 24+.
Им была нужна точка расширения.
Stream Gatherers дают тебе встроенные gatherer’ы для типичных stateful-операций, а также возможность определять собственные intermediate-операции, оставаясь внутри Stream pipeline.
Ниже простой пример батчинга фиксированного размера через
windowFixed 👇Требуется Java 24+.
❤2
Spring Boot легко интегрируется с Apache Kafka для реализации event-driven архитектур.
Сначала добавляешь необходимую зависимость в
После этого можно реализовать consumer’ы и producer’ы как Java-объекты:
👉 Java Portal
Сначала добавляешь необходимую зависимость в
pom, затем можешь настроить её в application.xml, указав, как подключаться к кластеру Apache Kafka, а также как определены consumer’ы и producer’ы.Here the required dependency:
<dependency>
<groupId>org.springframework.kafka</groupId>
<artifactId>spring-kafka</artifactId>
</dependency>
Configuration example:
spring:
kafka:
bootstrap-servers: localhost:9092
producer:
key-serializer: org.apache.kafka.common.serialization.StringSerializer
value-serializer: org.springframework.kafka.support.serializer.JsonSerializer
acks: all
retries: 3
consumer:
group-id: my-service-group
auto-offset-reset: earliest
key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer
После этого можно реализовать consumer’ы и producer’ы как Java-объекты:
Producer:
@Service
public class MessageProducer {
private final KafkaTemplate<String, String> kafkaTemplate;
public MessageProducer(KafkaTemplate<String, String> kafkaTemplate) {
this.kafkaTemplate = kafkaTemplate;
}
public void send(String message) {
kafkaTemplate.send("demo-topic", message);
}
}
Consumer:
@Service
public class MessageConsumer {
@KafkaListener(topics = "demo-topic", groupId = "demo-group")
public void listen(String message) {
System.out.println("Received: " + message);
}
}
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Spring Boot: с
#SpringBoot #SoftwareEngineering
👉 Java Portal
@RestControllerAdvice можно глобально обрабатывать конкретные типы исключений вместо того, чтобы разбрасывать try/catch по всему коду.#SpringBoot #SoftwareEngineering
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3