Java: Если нужно читать небольшие файлы, можно использовать Files.readAllLines() — это более прямой и простой способ.
#SpringBoot #JavaDev

👉 Java Portal

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

Встраиваемый движок AI-агента для любого Java-приложения — CLI · REST API · веб Playground

Базовая логика максимально простая: когда модели нужно вызвать инструмент, она выполняет его, записывает результат обратно в контекст и продолжает выполнение. Весь этот цикл упакован в Java-библиотеку и слой приложения на Spring Boot, поэтому его можно напрямую встроить в бизнес-систему или использовать как CLI, REST-сервис или веб Playground.

👉 Java Portal

Spring Boot: избегай FetchType.EAGER, если в этом нет реальной необходимости.

❌ Пометка связи как EAGER заставляет ORM загружать её при каждой загрузке сущности, независимо от того, вызываешь ли ты метод этой связи на самом деле.
#Springboot #РазработкаПО

👉 Java Portal

Подключения к базе данных — дорогая операция.
Открывать и закрывать их на каждый запрос?
Ещё хуже.

Я нашёл простой разбор того, как на самом деле работает пул соединений и почему это важно.

Ссылка: https://sagarshiroya.dev/posts/database-connection-and-pooling

#Database #SystemDesign

👉 Java Portal

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

👉 Java Portal

Реальная сила Stream Gatherers в Java 24: кастомная stateful-магия с ранним завершением

Java 24 добавляет Stream Gatherers (JEP 485) — серьёзное расширение Stream API.

Они позволяют создавать кастомные промежуточные операции с поддержкой stateful-преобразований, m-to-n отображений, раннего завершения и параллельного выполнения. В отличие от коллекторов (которые терминальные), Gatherers работают прямо внутри конвейера стримов.

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

С Gatherers код на стримах остаётся ленивым, читаемым, композиционным и переиспользуемым. Теперь Stream API выглядит завершённым для реальных сценариев обработки данных.

👉 Java Portal

В Java можно использовать Optional.orElseThrow() для реализации так называемого fail-fast поведения.

✅ Fail-fast означает, что ошибки фиксируются ближе к месту возникновения, за счёт чего стек вызовов проще читать и анализировать
#Java #РазработкаПО

👉 Java Portal

Polling vs Long Polling vs Webhooks vs SSE

Четыре способа получать обновления от сервера. Каждый даёт свой баланс между простотой, эффективностью и «почти реалтайм» доставкой.

Вот как они отличаются:

— Polling
Клиент каждые несколько секунд отправляет запрос: «есть что-то новое?». Сервер отвечает сразу — независимо от наличия данных. Большинство ответов пустые, что тратит ресурсы клиента и сервера. Подходит для сценариев вроде статуса заказа, где допустима задержка и важна простота реализации.

— Long Polling
Клиент отправляет запрос, а сервер держит HTTP-соединение открытым до появления данных или таймаута. Пустых ответов значительно меньше, чем в обычном polling. Использовался, например, в чатах для приближения к реалтайм-доставке сообщений.

— SSE (Server-Sent Events)
Клиент открывает постоянное HTTP-соединение, сервер стримит события по мере появления. Односторонний канал, лёгкий, работает поверх обычного HTTP. Многие AI-интерфейсы стримят ответы токен за токеном именно через SSE.

— Webhooks
Вместо опроса клиентом, сервис сам отправляет HTTP POST на заранее зарегистрированный callback URL при наступлении события. Stripe использует для подтверждения платежей, GitHub — для событий push. Клиент не держит соединение и не делает запросы, просто принимает вызовы.

Часто используется комбинация: polling для простых статусов, SSE для стриминга, webhooks для событий.

👉 Java Portal

Аккуратная идея из превью JDK 24: JEP 487, Scoped Values.

Scoped Values направлены на то, чтобы сделать общий неизменяемый контекст более предсказуемым по сравнению с ThreadLocal, особенно в современном конкурентном коде.

Небольшой пример 👇

Совет по Java:

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

Используй готовый метод:
Collections.frequency(...)

Пример:

int count = Collections.frequency(
    List.of("red", "green", "red"),
    "red"
);
System.out.println(count); // 2

👉 Java Portal

Микросервисы — это хаос без этих паттернов

👉 Java Portal

Java: если нужно писать переносы строк, соответствующие ОС, используй System.lineSeparator().


👉 Java Portal

💡Spring Boot: задавайте границы @ComponentScan аккуратно, чтобы не сканировать целые пакеты по ошибке.

Предположим, вы используете что-то вроде @ComponentScan("com.mycompany"):

❌Увеличивается время сканирования classpath
❌Замедляется запуск приложения
❌Могут подгружаться классы, не предназначенные быть Spring-компонентами

Лучшие практики:

✅Полагаться на значения по умолчанию:

@SpringBootApplication
public class MyApplication { }

По умолчанию сканируются только подпакеты пакета, где находится MyApplication

✅Сканировать конкретные подпакеты:

@ComponentScan({
    "com.mycompany.myapp.product",
    "com.mycompany.myapp.order"
})

👉 Java Portal

Основные области памяти JVM:

▪️Heap (куча)
Общая для потоков
Хранит объекты и экземпляры, управляется сборщиком мусора

▪️Method Area (область методов)
Общая для потоков
Метаданные классов, статические переменные, байткод

▪️Runtime Constant Pool (пул констант времени выполнения)
На класс, разделяется
Строковые литералы, ссылки на методы, константы

▪️JVM Stack (стек JVM)
На поток
Фреймы вызовов, локальные переменные, адреса возврата

▪️Native Stack (нативный стек)
На поток
Выполнение нативного кода через JNI

▪️Program Counter (PC регистр)
На поток
Текущая инструкция, которую выполняет поток

▪️Code Cache (кэш кода)
Общий
Машинный код после JIT-компиляции

▪️Direct Memory (off-heap)
Общая
Память вне кучи для высокопроизводительного ввода-вывода

Разбиение кучи:

▪️Eden
Новые объекты создаются здесь

▪️Survivor
Краткоживущие объекты перед продвижением

▪️Old Generation
Долгоживущие объекты

👉 Java Portal

Совет по Java: избегайте глубокой вложенности if-else — используйте guard clauses (ранний выход)

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

✗ Плохо: вложенные if-else

* сложно читать
* логика размазана
* любое изменение усложняет код

✓ Хорошо: guard clauses (ранний выход)

* проверки сразу отсекают невалидные состояния
* основной сценарий читается сверху вниз
* код короче и понятнее

Почему guard clauses — профессиональный подход:

* снижают когнитивную нагрузку
* делают бизнес-логику очевидной
* упрощают рефакторинг и тестирование
* хорошо сочетаются с fail-fast подходом

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

В результате код становится:

* линейным
* предсказуемым
* удобным для поддержки

На уровне синтаксиса это мелочь, но на уровне качества кода разница существенная.

👉 Java Portal

Совет по Java: удаляйте неиспользуемые импорты и переменные — это улучшает читаемость кода.

До:

import java.util.Date;   // неиспользуемый импорт
import java.util.Scanner;

public class Greeting {
    private int age;     // неиспользуемая переменная

    public void sayHello() {
        Scanner sc = new Scanner(System.in);
        System.out.println("Hello, world!");
        sc.close();
    }
}

После:

import java.util.Scanner;

public class Greeting {

    public void sayHello() {
        Scanner sc = new Scanner(System.in);
        System.out.println("Hello, world!");
        sc.close();
    }
}

#Java #CleanCode

👉 Java Portal

Spring Boot: можно обрабатывать CORS глобально через WebMvcConfigurer

CORS — это механизм, который позволяет веб-приложению на одном домене (origin) получать доступ к ресурсам с другого домена.

👉 Java Portal

SOLID в Java: принцип подстановки Лисков (LSP) утверждает:

==> Объекты базового класса должны заменяться объектами подклассов без проблем.

× Плохой пример

* Есть класс Vehicle с методом startEngine().
* Наследуемся в Bicycle, но… у велосипеда нет двигателя, и метод выбрасывает исключение.

Такая иерархия:

class Vehicle {
    public void startEngine() { ... }
}

class Bicycle extends Vehicle {
    @Override
    public void startEngine() {
        throw new UnsupportedOperationException("Bicycles don't have engines!");
    }
}

* Любой тест, который ожидает, что любой Vehicle сможет запустить двигатель, падает.
* Подкласс ведёт себя иначе, чем базовый класс — LSP нарушен.

✓ Как исправить

Разделить ответственность через интерфейсы:

interface Vehicle {}

interface Motorized {
    void startEngine();
}

class Car implements Vehicle, Motorized {
    public void startEngine() { ... }
}

class Bicycle implements Vehicle {
    // без двигателя — всё корректно
}

Теперь только те объекты, которым действительно нужен двигатель, реализуют Motorized.

* Подклассы не должны ломать ожидания, заданные базовым классом
* Поведение лучше разделять, чем «затыкать» методы исключениями
* LSP делает код предсказуемым и безопасным для расширения

👉 Java Portal

Кто-то выложил в опенсорс инструмент, который парсит бизнесы из Google Maps по всему миру.

Название, адрес, телефон, сайт, отзывы, часы работы — всё собирается. Достаточно ввести поисковый запрос, и он выгружает данные в CSV.

Проект на 100% с открытым исходным кодом.

👉 Java Portal