gRPC в Java раньше означал proto-файлы, codegen, build-плагины, настройку сервера и client channels. Куча возни ещё до первого hello world.

Spring Boot 4.1 закрывает большую часть этой рутины.
Если ты умеешь писать REST-приложение, базовые шаги уже знакомы:
→ описать контракт
→ добавить bean с @GrpcService
→ заинжектить stub на клиенте

Полный сервер, клиент и in-memory тест с нуля 👇

https://github.com/danvega/hello-grpc

👉 Java Portal

Совет по Java: не ловите Exception на всякий случай

Плохая практика:

catch (Exception e)

Такой код скрывает реальные проблемы. Для приложения одинаково начинают выглядеть ошибки бизнес-логики, NullPointerException, проблемы с памятью и другие сбои.
Ловите только те исключения, которые действительно можете обработать:

catch (IOException e) { ... }
catch (JsonProcessingException e) { ... }
catch (DuplicateKeyException e) { ... }

Тогда становится понятно:
что именно пошло не так;
какие ошибки ожидаемы;
какие нужно логировать;
какие должны прерывать выполнение.

И ещё одно правило:

catch (Throwable t)

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

Лови только то, что умеешь исправить. Остальное пусть поднимается выше по стеку вызовов.

👉 Java Portal

Совет по Spring: ставь circuit breaker на удалённые вызовы

Если сервис ходит в другой сервис через Feign, этот вызов может зависнуть, упасть или начать возвращать ошибки.

@CircuitBreaker(name = "CircuitBreakerService")
String getInstance();

Circuit breaker временно «размыкает цепь», когда ошибок слишком много. Вместо бесконечных ретраев и просадки всего приложения ты отдаёшь fallback:

public String getAuthorServiceInstanceFallback(Exception ex) {
    return "Fallback content";
}

В application.yml можно задать порог ошибок и время ожидания:

failure-rate-threshold: 50
wait-duration-in-open-state: 5s

Идея простая: внешний сервис упал — твоё приложение деградирует контролируемо, а не валится следом.

👉 Java Portal

DBeaver уже 15 лет остаётся де-факто стандартом среди SQL-клиентов.

Инструмент мощный, но это ещё и тяжёлый Java-монолит, который может запускаться по 20 секунд.

Кто-то решил переписать его с нуля на Rust и добавить возможности, которых в DBeaver никогда не было.

Проект называется Tabularis. 2.5 тыс. звёзд. Лицензия Apache 2.0. Последняя активность — 17 часов назад.

Самое интересное:

Tabularis создал один разработчик — Debba — как эксперимент по AI-assisted разработке.

Цель была простой: проверить, насколько далеко AI-агенты способны зайти при создании реального продукта.

В итоге получилось 55 релизов, 1192 коммита и SQL-клиент, который уже конкурирует с продуктами компаний, где над подобными инструментами работают десятки инженеров.

Что есть в Tabularis, а в DBeaver нет:

✅ Встроенный MCP-сервер — Claude, Cursor и Windsurf могут читать схему БД и выполнять запросы прямо из чата
✅ SQL Notebooks с графиками внутри ячеек и общими переменными между ними
✅ Визуальный EXPLAIN с AI-анализом плана выполнения
✅ Визуальный конструктор запросов с drag-and-drop JOIN'ами
✅ Автоматическая генерация ER-диаграмм
✅ Поддержка PostgreSQL, MySQL/MariaDB, SQLite и ClickHouse через плагины
✅ Редактор на базе Monaco с интеллектуальным автодополнением
✅ Без телеметрии, аккаунтов и подписок

Чего пока нет в Tabularis, но есть в DBeaver:

❌ SQL Server
❌ Oracle

Если работаешь с ними, DBeaver пока остаётся более очевидным выбором.

Во всех остальных случаях Tabularis запускается примерно за 2 секунды, занимает меньше ресурсов и позволяет AI-агентам работать с базой напрямую.

https://github.com/TabularisDB/tabularis

👉 Java Portal

Java: используйте полиморфизм вместо цепочек instanceof.
Проверки типов часто приводят к разрастающимся if/else, нарушают принцип Open/Closed и заставляют изменять существующий код при добавлении новых сущностей.

❌ До:

public String describe(Animal animal) {
    if (animal instanceof Dog) {
        return "Woof";
    } else if (animal instanceof Cat) {
        return "Meow";
    } else if (animal instanceof Cow) {
        return "Moo";
    }

    throw new IllegalArgumentException("Unknown animal");
}

Каждый новый тип требует правки метода.

✅ После:

public interface Animal {
    String sound();
}

public final class Dog implements Animal {
    public String sound() {
        return "Woof";
    }
}

public final class Cat implements Animal {
    public String sound() {
        return "Meow";
    }
}

public final class Cow implements Animal {
    public String sound() {
        return "Moo";
    }
}

public String describe(Animal animal) {
    return animal.sound();
}

Преимущества:
→ нет цепочек instanceof и приведения типов
→ меньше условной логики
→ проще расширять систему новыми типами
→ соблюдается принцип Open/Closed
→ поведение находится внутри самого объекта, а не размазано по коду

Добавить новое животное теперь можно без изменения существующей логики:

public final class Sheep implements Animal {
    public String sound() {
        return "Baa";
    }
}

Клиентский код останется прежним:

describe(new Sheep());

Пусть объекты сами решают, как себя вести. Именно для этого и существует полиморфизм. #Java #OOP

👉 Java Portal

Java: отдавай предпочтение неизменяемым объектам (immutable), чтобы упростить потокобезопасность.

❌ Изменяемое состояние, разделяемое между потоками

public class Balance {
    private BigDecimal amount = BigDecimal.ZERO;

    public void deposit(BigDecimal v) {
        amount = amount.add(v);
    }

    public BigDecimal get() {
        return amount;
    }
}

Если два потока одновременно вызовут deposit(), возможны потерянные обновления (lost updates), гонки данных (race conditions) и чтение неконсистентного состояния.

✅ Неизменяемый объект — обновление через создание нового экземпляра

public record Balance(BigDecimal amount) {

    public Balance deposit(BigDecimal v) {
        return new Balance(amount.add(v));
    }
}

Вместо изменения существующего объекта создаётся новый.
Потоки могут безопасно работать со своими снимками состояния (snapshot), а каждый вызов deposit() возвращает новый объект.

✅ Неизменяемые коллекции

List<String> roles = List.of("READ", "WRITE");

Map<String, Integer> limits =
        Map.of("free", 10, "pro", 100);

Такие коллекции можно безопасно передавать между потоками без дополнительной синхронизации.

✅ Защитная копия (defensive copy)
Если исходная коллекция всё ещё изменяемая:

List<String> snapshot = List.copyOf(mutableRoles);

Создай неизменяемую копию перед публикацией другим частям приложения.

На практике immutable-подход позволяет существенно сократить количество synchronized, блокировок и ошибок многопоточности. Поэтому современные API Java (record, List.of(), Map.of(), Optional, LocalDateTime) активно используют неизменяемые объекты по умолчанию.

👉 Java Portal

Spring Boot 4.1 добавляет всего одно свойство:

spring.datasource.connection-fetch=lazy

По умолчанию методы с @Transactional получают соединение с БД сразу при открытии транзакции, даже если запрос в итоге так и не выполняется.

Попадание в кэш, ранний return, долгий вызов внешнего API перед сохранением данных — во всех этих случаях соединение просто простаивает без дела.

Режим lazy откладывает получение соединения до момента, когда действительно выполняется SQL-запрос.

Dan Vega собрал демо, которое показывает это на метриках HikariCP.
Количество захватов соединений (acquire count) падает примерно со 100 до почти 0.

👉 Java Portal

Java-паттерны: Builder

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

new Order("Mario", "Laptop", 2, true, "Leave at door");

Через несколько месяцев уже сложно понять, что означает true, а при добавлении новых параметров конструктор быстро становится неудобным.
Builder решает эту проблему:

Order order = Order.builder()
    .customer("Mario")
    .product("Laptop")
    .quantity(2)
    .express(true)
    .note("Leave at door")
    .build();

Преимущества:
✅ Именованные параметры делают код читаемее
✅ Можно задавать значения в любом порядке
✅ Удобно работать с необязательными полями
✅ Значения по умолчанию задаются в Builder
✅ Валидацию можно выполнять один раз в build()
✅ Нет путаницы с конструкторами из 5–10 аргументов

Builder особенно полезен для DTO, конфигураций, запросов к API и объектов с большим количеством параметров.
Поэтому его часто можно встретить в Java-проектах и библиотеках вроде Lombok, где достаточно добавить аннотацию @Builder.

👉 Java Portal

SQLBolt - изучайте SQL с помощью простых интерактивных упражнений.

https://sqlbolt.com/

👉 Java Portal

💡 Java tip: Use the Stream API для работы с коллекциями в декларативном стиле.

List<String> names = users.stream()
    .filter(User::isActive)
    .map(User::getName)
    .sorted()
    .toList();

Пиши, что тебе нужно получить из данных. Не расписывай цикл вручную. Stream сделает это короче и чище.

👉 Java Portal

Spring Boot 4.1 приносит с собой много новых фич, включая автоконфигурацию job repository для Spring Batch на базе MongoDB.

\ Читай об этом здесь

👉 Java Portal !

Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:

COPY . .
RUN npm install

должно быть:

COPY package*.json ./
RUN npm install
COPY . .

почему это важно?

docker кэширует каждую инструкцию как отдельный слой
исходный код меняется с каждым коммитом
поэтому COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборке
если поменять порядок, слой с установкой зависимостей остаётся в кэше даже при изменении кода, потому что он зависит только от package.json
одна перестановка строк. экономит 40+ секунд на каждой пересборке. кэшируй зависимости, а не код.

👉 Java Portal

Java Tip: Не перегружайте методы параметрами

Если метод принимает слишком много аргументов, возрастает риск передать значения в неправильном порядке, а код становится сложнее читать и поддерживать.

❌ Плохо:

createUser(firstName, lastName, street, city, zip, country);

✅ Лучше сгруппировать связанные данные в отдельный объект:

createUser(firstName, lastName,
    new Address(street, city, zip, country));

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

Если несколько параметров всегда используются вместе — вероятно, им нужен собственный класс или record.
#Java #Refactoring #CleanCode

👉 Java Portal

AI-инструменты можно любить и ненавидеть, но работать без них в IT уже практически невозможно 🤩

Коллеги из AvitoTech 11 июля зовут в их офис на Лесной на AI Hardcore Day. Приглашают тех, кто каждый день сталкивается с AI в работе и даже пишет своих AI-агентов. Обещают доклады и нетворкинг-сессию на террасе после — и всё это без записи.

💫 Среди тем:
— Spec-Driven Development: теория, инструменты, практика.
— Разработка и тестирование MCP для внутренних агентных систем аналитики.
— Выпрямляем руки агентов: как сделать MCP удобными и действительно полезными.
— Атаки на GenAI-агентов: OWASP на практике.

➡ Регистрация тут!

Что нового в PostgreSQL 19?

PostgreSQL 19 продолжает одну важную тенденцию. Postgres превращается во что-то гораздо большее, чем просто реляционная база.

Самые интересные новинки:

Графовые запросы через SQL/PGQ
PostgreSQL 19 научился выполнять SQL Property Graph Queries. Теперь можно запрашивать связи прямо на SQL, без отдельной графовой базы. Пригодится для соцсетей, рекомендаций, поиска мошенничества и графов зависимостей.

GROUP BY ALL
Вместо того чтобы перечислять все колонки в GROUP BY, пишешь GROUP BY ALL. Postgres сам группирует по неагрегатным колонкам. Меньше шаблонного кода, меньше ошибок.

WAIT FOR LSN
Фича для приложений, которые используют реплики чтения. Позволяет подождать, пока реплика догонит основную базу, прежде чем читать данные. Полезно для консистентности «прочитал то, что написал».

Лучшая поддержка JSON
Postgres и дальше улучшает работу с полуструктурированными данными, не теряя при этом SQL, индексы, соединения и транзакции.

PostgreSQL 19 пока в бете. Детали могут поменяться к релизу. Но направление понятно. Postgres потихоньку становится одной платформой под всё: реляционные данные, документы, графы, аналитика и векторы для AI.

👉 Java Portal

Твой Java-проект в Claude Code не должен каждый раз стартовать с пустого промпта.

claude-code-java — это готовая рабочая область для Java-разработчиков. Внутри навыки, шаблоны, MCP-конфиг и скрипты для настройки. Всё, что нужно для типичной Java-работы.

Он делает Claude Code одинаково полезным в любом проекте. Подсовывает структурированные markdown-скиллы для код-ревью, тестов, коммитов, архитектурных решений и работы с Maven.

Что внутри:

- 18 навыков для Java: код-ревью, архитектура, Spring Boot, JPA, Maven, безопасность, логирование
- Быстрый старт через setup-project.sh — создаёт .claude/, привязывает навыки, генерирует CLAUDE.md
- Можно брать по одному навыку, выборочно или сразу всё
- В комплекте шаблоны CLAUDE.md, MCP-конфиг, настройки
- README подсказывает, как подключить те же навыки к автоматическому PR-ревью

Открытый исходный код под MIT.

👉 Java Portal

Java: Начиная с Java 8, отдавайте предпочтение java.time вместо Date и Calendar.

API из java.time неизменяемые (immutable), потокобезопасные (thread-safe) и намного понятнее в использовании.

Преимущества:

LocalDate.of(2026, 5, 31) — май действительно означает май.
Нет изменяемых объектов, которые легко случайно испортить.
Форматтеры из DateTimeFormatter потокобезопасны.
Удобная работа с часовыми поясами через ZonedDateTime.
Более читаемый и предсказуемый код.

Вместо:

Date
Calendar
SimpleDateFormat

Используйте:

LocalDate
LocalDateTime
ZonedDateTime
Instant
DateTimeFormatter

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

👉 Java Portal

Исторический момент. Новый HTTP-метод в стандарте.

QUERY. Альтернатива GET и POST.

Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.

Только что повышен до Proposed Standard.

👉 Java Portal