Java Guru 🤓

👩‍💻 Spring AI 2.0 на практике: добавляем AI в Spring Boot и доводим до production

Приглашаем на открытый урок.

🗓 30 сентября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Разработчик на Spring Framework».

На занятии мы разберем:
✔️От обычного Spring Boot-сервиса к AI-функции. Подключим Spring AI 2.0 и разберём основные компоненты без долгой теории.
✔️Соберём рабочий кейс с live coding. Используем ChatClient, structured output и @Tool, чтобы модель могла обращаться к Java-сервисам и использовать реальные данные приложения.
✔️Попробуем сломать наше приложение. Посмотрим, что произойдёт при долгом ответе модели, ошибке провайдера, некорректном tool call или утечке чувствительных данных.
✔️Доведём решение до production. Разберём таймауты, retries, контроль выполнения tools, observability и возможность смены LLM-провайдера.

Кому будет интересно:
Java backend-разработчикам уровня Junior+/Middle и выше, которые уже работают со Spring и хотят разобраться, как AI-функции встраиваются в Java-приложения без перехода в Python/ML-разработку.

🔗 Ссылка на регистрацию: https://vk.cc/d1YxD2

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Чем анонимный внутренний класс отличается от лямбды?

Лямбда-выражение имеет более легковесный синтаксис. Не нужно явно указывать тип функционального интерфейса, который лямбда реализует – он автоматически выведется из контекста. Лямбда-выражения добавлены в язык в первую очередь как синтаксический сахар.

С другой стороны, у класса есть поля. Экземпляр анонимного класса сохраняет свое состояние между вызовами, и меняет его при необходимости. Для лямбды доступен лишь захват и effectively final использование внешних переменных.

Лямбдой реализуется только функциональный интерфейс. Функциональный интерфейс – это тип с единственным абстрактным методом. Анонимным классом же можно расширить любой расширяемый класс или реализовать интерфейс с любым количеством абстрактных методов.

Анонимный класс создает новый скоуп, лямбда работает в текущем. Это значит, что объявление переменной с именем, которое уже используется снаружи, в лямбде вызовет ошибку компиляции «variable is already defined», в анонимном классе скроет (shadowing) внешнюю переменную.

С точки зрения реализации JVM, для лямбды не создается дополнительного .class файла, как это происходит для анонимного класса. Соответственно, не происходит и обычной загрузки и верификации класса. Вместо этого используется механизм invokedynamic и класс генерируется на лету с помощью LambdaMetafactory. Так что лямбда-выражения обычно работают быстрее.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

Как узнать, является ли A подтипом B?

В Java доступны три способа проверки совместимости типов. Функционально они ничем не отличаются, применяются для разных наборов аргументов. В порядке убывания быстродействия:

instanceof – бинарный оператор, самый быстрый и самый используемый. Если есть экземпляр A и можно указать B явно, выбирать надо его. Если A (точнее тип хранящей экземпляр A переменной) и B не из одной цепочки наследования – экземпляр точно не может быть подтипом B и компиляция упадет с ошибкой inconvertible types.

Class::isInstance – метод принимает параметром объект типа A. Его стоит выбрать, когда экземпляр A в наличии, но B – неизвестный на этапе компиляции тип. То есть, для переменных A a и Class bClass, можем проверить bClass.isInstance(a).

Class::isAssignableFrom – принимает Class<A>. Единственное, что остается, если экземпляра A нет. bClass.isAssignableFrom(aClass).

Есть еще четвертый способ – имея экземпляр типа A привести его к B. Если типы были несовместимы, приведение выбросит ClassCastException. Это во всех смыслах плохой способ, построению логики программы на исключениях нет оправдания. Подробная аргументация описана в Effective Java Item 57.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

Нововведения Java 27

Java 27 вышла в релиз. В него вошли четыре узконаправленные правки и пять превью/инкубаторов. Разбираем изменения в сборщике мусора, улучшения JFR, постквантовый TLS 1.3 и компактные заголовки объектов, экономящие треть памяти.

Читать статью

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

Чем отличается interface от @⁠interface?

Среди интерфейсов выделяется особая группа, которая не объявляет никаких методов. Пример такого интерфейса – Serializable. Такие интерфейсы добавляют классу некую семантику, которая позже используется либо с помощью рефлексии (и instanceof), либо вообще не программно, а как информация для разработчиков и инструментов разработки. Это маркерные интерфейсы. Маркерный интерфейс представляет метаинформацию класса.

Начиная с Java 1.5 в языке появился новый вид типов – аннотации. Они берут на себя и расширяют возможности маркерного интерфейса:
1. Можно применять аннотацию не только к классу или интерфейсу, но почти к чему угодно: к пакетам, к методам, их параметрам, переменным. Полный список представлен в перечислении ElementType;
2. Аннотация может нести данные в своих элементах
3. Аннотация может не присутствовать в рантайме, или даже остаться только в исходнике, не попав в байткод вовсе. Определяется ее RetentionPolicy;
4. Можно сделать аннотацию не наследуемой, просто не помечая ее @Inherited;
5. И конечно же, синтаксис. Примененная аннотация с первого взгляда отличается от настоящих интерфейсов.

Joshua Block в главе 37 Effective Java выделяет два преимущества маркерных интерфейсов перед аннотациями на этапе компиляции:
1. Можно требовать использование только маркированного параметра, так как маркерный интерфейс – это еще и тип;
2. Можно сузить применяемость маркера к только определенным типам, сделав интерфейс их наследником.

Возвращаясь к вопросу, ключевое слово @interface объявляет аннотацию, interface – интерфейс.

В результате компиляции в .class-файле аннотация превращается в интерфейс-наследник java.lang.annotation.Annotation, помеченный флагом ACC_ANNOTATION. Элементы превращаются в абстрактные методы. Этим объясняется синтаксис объявления. Специфичные для аннотаций атрибуты описаны в JVMS 4.7.16-4.7.22.

К слову, конструкции вида @something в javadoc называются тэгами. Они выглядят похоже на аннотации, также представляют метаинформацию для документации, но технически не имеют с ними ничего общего.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

Знаете, что в Java можно безопасно создать файл и не перезаписать старый?

Обычно при записи легко случайно затереть существующий файл:

Files.writeString(path, json);

Если файл уже есть, его содержимое будет заменено.

Для логов, экспортов, отчётов, временных файлов и сохранения пользовательских данных это может быть опасно.

В таких случаях можно использовать

StandardOpenOption.CREATE_NEW:

Files.writeString(path, json, StandardOpenOption.CREATE_NEW);

Теперь Java создаст файл только если его ещё нет.

Если файл уже существует, будет выброшено исключение:

FileAlreadyExistsException

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

Например, можно явно обработать ситуацию:

try {
    Files.writeString(path, json, StandardOpenOption.CREATE_NEW);
} catch (FileAlreadyExistsException e) {
    throw new IllegalStateException("Export already exists", e);
}

Так поведение становится предсказуемым: код либо создаёт новый файл, либо честно сообщает, что такой файл уже есть.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

В чём разница между интерпретатором, AOT и JIT-компилятором?

Интерпретация – простое последовательное воспроизведение кода программы, команда за командой.

AOT-компиляция (ahead-of-time, статическая) – процесс превращения текста на языке программирования в нативный код на машинном языке. Так работают языки вроде C++. В современных JDK можно получить настоящий ahead-of-time скомпилированный машинный код с помощью утилиты jaotc.

JIT-компиляция (just-in-time, динамическая) – «умная» интерпретация. Среда выполнения анализирует исполняемый код, оптимизируя часто вызываемые участки. Таким способом программа работает значительно быстрее, и сохраняет при этом преимущества платформо-независимости оригинального кода. Именно с JIT-компиляцией связана необходимость «прогрева» программ перед тестированием производительности.

Эти термины относятся не только к JVM, но и ко множеству других языков программирования. Конкретно в Java байткод – интерпретируемый. Но в JVM по умолчанию работает JIT-компилятор. А процесс компиляции Java-кода в байткод можно назвать AOT-компиляцией.

Для взаимодействия с JIT-компилятором из кода в JDK поставляется класс java.lang.Compiler. Его методом disable() можно отключить JIT и перевести программу в режим простой интерпретации. Сейчас этот класс объявлен устаревшим и готовится к удалению.

Более красивый способ влиять на компилятор – передавать его настройки параметрами JVM. Параметр -Djava.compiler=NONE также переключит программу с JIT на интерпретатор. В теории, через этот же параметр можно подключить другой JIT-компилятор, альтернативный встроенному в JVM.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

От чего может случиться NoSuchMethodError?

Как очевидно из названия, программа пытается вызвать метод, которого не существует. В большинстве случаев это приводит к ошибке еще на этапе компиляции. Но в некоторых ситуациях о проблеме становится известно только во время выполнения, и тогда выбрасывается это исключение.

Вариантов таких ситуаций два. Либо проект был изменен и частично перекомпилирован; либо программа несовместима с внешней зависимостью: например неправильная версия jar-библиотеки в classpath.

Исключение NoSuchMethodError наследуется от LinkageError. Все такие ошибки – признаки несовместимых изменений после компиляции класса.

Не следует путать эту ошибку с NoSuchMethodException – исключением, которое случается при попытке вызвать несуществующий метод с помощью Reflection API. Важное отличие в том, что это не Error, его можно ловить и обрабатывать.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

N+1 в Spring Boot выглядит безобидно, пока прод не начинает молиться на базу данных.

Классический сценарий:

Вы грузите список заказов:

orderRepository.findAll()

А потом в цикле обращаетесь к order.getItems().

Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items.

100 заказов = 101 SQL-запрос.

И вот здесь спасает @EntityGraph.

Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу:

@EntityGraph(attributePaths = {"items"})

В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу.

Что получаем:

- меньше SQL-запросов
- меньше нагрузки на БД
- чище код репозитория
- без ручного JPQL
- fetch-стратегия управляется точечно под конкретный кейс

LAZY сам по себе не зло. Зло - когда вы не контролируете, где и как он срабатывает.

@EntityGraph - один из самых простых способов держать N+1 под контролем в Spring Boot.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

Шпаргалка по аннотациям Spring Boot!

Например, @RestController используется для создания REST API, @Autowired — для внедрения зависимостей, а @Transactional помогает управлять транзакциями.

На картинке — основные аннотации Spring Boot, Spring MVC, JPA, Security, Validation и тестирования, которые чаще всего используются в реальных проектах.

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

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

Микросервисы — плохой выбор по умолчанию для 94% команд.

Зачем разбивать приложение на набор сервисов, которым нужно общаться через сеть.

На бумаге это выглядит как «правильный» подход. Масштабирование звучит привлекательно.

Но на практике я видел, как это ломается, шесть раз.

Команды из 5 инженеров поднимали 11 сервисов с несколькими очередями сообщений. Всё становилось медленнее.

Деплой, который занимал минуты, растягивался до 35 минут из-за зависимостей.

Отладка превращалась в кошмар: один баг — и приходится трейсить запрос через несколько сервисов и кодовых баз.

Сложность не уменьшилась. Она просто распределилась.

Микросервисы — это решение под масштабирование, но большинство команд внедряют их слишком рано, когда проблемы масштаба ещё нет.

Если ты всё ещё работаешь на localhost, основная проблема — не масштаб. Это стабильный релиз.

Когда микросервисы имеют смысл:

- команды блокируют работу друг друга
- части системы требуют независимого масштабирования
- есть нормальная трассировка в проде, и можно отлаживать без угадывания

Если этого нет — платишь налог распределённых систем без реальной выгоды.

Начинай с монолита и держи модульность. Делить стоит только тогда, когда связность начинает тормозить разработку.

Большинство обсуждений «нам нужны микросервисы» на деле не про архитектуру.

Они про грязную кодовую базу или болезненные деплои.

Сначала решаются эти проблемы.

Простые системы легче понимать. Перегруженные обычно разваливаются под собственным весом.

Полезные ресурсы по Java 👩‍💻| Наш канал в MAX 🟪

🔴 Тестовый собес с Java-разработчиком уже завтра! 
[+ разбор 50 сложных вопросов в подарок ]

16 сентября (уже завтра!) в 19:00 по мск приходи онлайн, чтобы посмотреть на настоящее интервью на Middle Java-разработчика!

Собеседование проведёт Виктор Анохин — Senior из Wildberries, ех-Билайн

Как это будет:

📂 Виктор задаст разработчику вопросы и задачи, которые могут спросить на реальном собесе

📂 После каждого ответа респондента ты услышишь подробный комментарий от ментора и поймёшь, чего на самом деле ожидает собеседующий на интервью

📂 В конце сможешь задать любой вопрос Виктору и получить на него развёрнутый ответ

Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы

И ты можешь посмотреть его бесплатно 🔥
Только завтра, в прямом эфире!

🎁 Подарок для всех, кто зарегается на веб — файл с ОТВЕТАМИ НА 50 СЛОЖНЫХ ВОПРОСОВ с Java-собеседований 🔥

Переходи в бот, чтобы попасть на эфир и забрать подарок 👉 @shortcut_sh_bot

Реклама.
О рекламодателе.