Всем привет!

Есть много способов получить данные из БД с помощью JPA:
1) JPQL
2) JPQL Native Query
3) HQL
4) Spring Data JPA Repository
5) Criteria API
6) QueryDSL
...

Предположим, нам нужно вернуть набор строк. Задать параметры запроса можно по-разному, а итог будет один - List или другая коллекция (Collection) с набором данных. Верно? Не совсем)
Если посмотреть на список возвращаемых Spring Data JPA данных https://docs.spring.io/spring-data/jpa/reference/repositories/query-return-types-reference.html#appendix.query.return.types то там можно увидеть много чего интересного. В т.ч. Stream.
А вот пример его использования: https://vladmihalcea.com/spring-data-jpa-stream/
Аналогично можно вернуть Stream и из обычного JPA - см. метод getResultStream, вот пример: https://thorben-janssen.com/jpa-2-2s-new-stream-method-and-how-you-should-not-use-it/

Зачем это может быть нужно?

Во-первых это просто красиво... Шучу. Если вы используете Stream в бизнес-логике - то кажется логичным использовать их и при обращении к БД.
А во-вторых: главная особенность стриминга - равномерная выборка данных. И в каждый момент данных в обработке будет одна запись.
Рассмотрим кейс, когда нужно обработать на клиенте миллион записей.

Ремарка: если у вас такой кейс - подумайте, нет ли проблем в архитектуре. Данные лучше обрабатывать на сервере СУБД. Если все же проблем нет - продолжим)

Так вот, какие у нас варианты:
1) вытащить на клиент миллион записей. Запрос к БД будет один, она выдержит, но с неплохой вероятностью можно убить клиент через Out of Memory.
2) организовать пагинацию, например, вот так: https://www.baeldung.com/spring-data-jpa-iterate-large-result-sets. Данных на клиенте в моменте не много, по размеру страницы, но запросов к БД ... тысяча.
3) использовать стримы. Запрос к БД один, данных на клиенте немного. Не обязательно одна запись, но в любом случае немного, детали ниже.

К слову, стриминг по БД с JPA аналогичен перемещению курсора по ResultSet в JDBC. С накладными расходами и плюшкам, которые дает сессия JPA, конечно.

И про объем данных на клиенте. Казалось бы - вытаскиваем записи поштучно. Но если не указать fetch size - объём предварительной выборки - для некоторых СУБД Hibernate вытащит на клиента все данные за раз, и мы вернемся к варианту 1 (((

#jpa #java_streams #rdbms

Всем привет!

Не отпускает меня тема AI)
Напомню, что с одной стороны AI ~= Python, но с другой стороны Java потихоньку подтягивается, о чем я уже писал на канале, см. по тегам.

Вот отличный пример генерации данных с помощью AI с запоминанием контекста на Spring AI https://piotrminkowski.com/2025/01/28/getting-started-with-spring-ai-and-chat-model/
Обратите внимание на "магию" Spring - в части преобразования ответа модели в коллекцию.
А вот тут https://piotrminkowski.com/2025/01/30/getting-started-with-spring-ai-function-calling/
на "магию" привязки функций, забирающих данные из API брокера и с сервиса-поставщика биржевой информации к вызову модели.
Красиво, черт возьми!)

P.S. Интересно, учитывая недетерминистическое поведение модели - всегда ли эта магия работает. Буду проверять)

#ai #java #spring

Всем привет!

Маленький факт. Судя по индексу языков TIOBE мы находимся на второй волне интереса к теме AI. И эта волна существенно сильнее первой.

P.S. Зеленая линия - Java, есть небольшой подъем после длительного спада

#ai #python #java

Всем привет!

Нашел забавную статью о том, как Java превратить в BrainFuck https://ru.wikipedia.org/wiki/Brainfuck
Статья https://habr.com/ru/articles/886080/
Всегда было ощущение, что это на условном Perl можно написать не очень понятную строку кода, выглядящую прилично, а на самом деле форматирующую диск C:) Ну или на Scala на худой конец. А тут Java.

У меня только один вопрос по первому примеру - где код программы, которая подбирала эти магические числа?
А второй отлично показывает, чем может быть вредно Reflection API. Убирать его конечно не надо, но подумать о защите для системных классов стоило бы.

#java

Можно ли быстро сделать и запустить single-file прототип на Java?

Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.
Не сказать, что Java ничего не делает в эту сторону:
1) JShell - позволяет просто запускать Java код без метода main построчно. Работает начиная с Java 9
2) JEP 330: Launch Single-File Source-Code Programs - не надо отдельно вызывать javac. Запуск программы работает через java HelloWorld.java. Работает с Java 11
3) JEP 477 Implicitly Declared Classes and Instance Main Methods - все тоже самое, но теперь не нужно объявлять класс (он создается неявно) и декларация метода main сильно упрощена. В режиме preview с Java 21

Но все это работает с простыми приложениями. А если нужны зависимости? Наш любимый Spring, например, с pom bom и кучей библиотек + Lombok. Да еще в нескольких файлах. Да еще хотелось бы не указывать параметры сборки в командной строке каждый раз, и не плодить лишних shell скриптов.
Когда-то подобная фича была в Spring Boot Cli - да, в Spring Boot и своя консоль. Но фичу выпилили, на мой взгляд зря. И из полезного в Cli остался по сути только аналог Spring Initialzr.
Но я отвлекся)

Кто ищет, тот всегда найдет - встречаем https://www.jbang.dev/documentation/guide/latest/index.html
Как это работает - хорошо проиллюстрировано по ссылке выше.
Я проверил на комбинации Spring Boot + Lombok все работает. Настройки из лежащего рядом application.properties подтягиваются. Единственный момент - были проблемы, если код разнесен по нескольким файлам - не обнаруживалась аннотация @Scheduled. Т.е. реализация multiple source file немного хромает, о чем разработчики предупреждают https://www.jbang.dev/documentation/guide/latest/organizing.html
Зато - все зависимости выкачиваются, код компилируется перед запуском, параметры компиляция настраиваются в файле с исходниками. Если надо - даже выкачивается Java. Принимает на вход java исходники, kotlin, упомянутый выше код для jshell, код внутри markdown (!!!) и можно даже так: jbang --code System.out.println("Hello World!")

Рекомендую к использованию!

#java #prototyping

PHP становится Java-ой?

Недавно посмотрел видео о перспективах PHP https://vkvideo.ru/video-224967259_456239053 Я на PHP писал мало, но т.к. он широко распространён - интересно, развивается ли он и как именно. Он развивается, и я этому не удивлён. Да, есть распространённое негативное мнение про PHP и его разработчиков. Любой простой язык привлекает непрофессионалов. Но ситуация сложнее, чем кажется, на это намекает официальный code style языка https://php-psr.ru/accepted/PSR-12-extended-coding-style-guide/ Обязательность строк разделителей, фиксированное число пробелов, регистр символов - все серьёзно. Небольшое отступление - к аббревиатуре PSR из статьи выше мы ещё вернёмся.

Так вот, PHP становится похожим на Java.

Чтобы понять как именно - стоит вспомнить, чем он характеризовался изначально?

1) динамическая типизация. От неё уходят, с костылями в виде объявления типов в комментариях и проверке статическим анализатором типа checkstyle. Причина - невозможно работать со сложным проектом и динамической типизацией. Если ты конечно не хочешь "гов..кодить".

2) интерпретация вместо компиляции. Тоже уходят, есть AOT и JIT компиляторы PHP. Также фреймворки, например, IoC контейнеры, могут предварительно сохранять конфигурацию на диске. По соображениям производительности

Да, в PHP тоже есть IoC контейнеры.

3) малоизвестный факт - исходно в PHP была т.наз умирающая модель процессов. После обработки запроса клиента контекст процесса полностью очищается. Такой true stateless. Причём очищались не просто клиентские данные, а все бины IoC контейнера, т.е. вообще все. Побочные эффекты такого подхода противоположные. Положительный: PHP компоненты инициализируются очень быстро, по другому никак. Отрицательный: на утечки памяти можно забить, т.е. "гов...кодим") Так вот, от этой модели тоже уходят. Снова по соображениям производительности

В общем язык развивается, т.к. наследие огромное.

P.S. Чтобы не было пренебрежительного отношения к PHP - поговорим про стандартизацию. В PHP есть такое понятие, как middleware. Вот его неплохое описание https://laravel.com/docs/12.x/middleware
Ключевой момент - компоненты middleware переиспользуются в различных фреймворках. Как это получается? Потому что многое стандартизируется, с помощью PSR. В Java тоже есть стандарты - JPA, JDBC,  http сервлеты и фильтры, но видится, что их меньше. Когда-то этим занимался проект Java EE, не смог, умер и воскрес, а за это время возникло несколько экосистем - Spring, Quarkus, Micronaut... И это я Kotlin не беру) Почему я назвал их экосистемами - каждая старается привязать к своим компонентам. Так что как ни странно - PHP выглядит более стандартизированным)

#java #PHP #lang

И снова новости AI

В Spring AI появилась возможность работы с embeddings - https://www.baeldung.com/spring-ai-embeddings-model-api
Напомню, embeddings - векторное представление привычных нам текстовых, графических или аудио данных. Для чего нужно работать с embeddings - ведь мы можем общаться с моделью текстом, а все остальное она сделает сама?
Детали тут - https://habr.com/ru/companies/otus/articles/787116/
А если вкратце - например, с их помощью мы можем тренировать свою локальную модель. Или перейти от "программирования на русском языке" к более низкоуровневым операциям, теперь и на Java. Примеры таких действия: найти похожие слова, подставить недостающее слово.

#ai #spring #java

Жонглирование JDK

Иногда нужно вести разработку нескольких сервисов, требующих разных версий JDK. Или нескольких релизов одного и того же сервиса. Или какое-то ПО на компьютере требует одной версии JDK, а разработка другой.
Все эти проблемы решает утилита jenv.
Неплохая статья по ней https://habr.com/ru/companies/surfstudio/articles/764442/

Прям скопирую оттуда абзац с ключевыми фичами:
1. Управление версиями Java: jenv позволяет установить и использовать несколько версий Java на одной машине.
2. Поддержка различных ОС: jenv может использоваться на macOS, Linux и Windows;
3. Управление переменными окружения Java: jenv может автоматически установить переменные окружения Java;
4. Управление настройками JVM: jenv позволяет настраивать параметры JVM для каждой версии Java, такие как размер кучи, аргументы командной строки и т. д.

Жаль, что я не знал о ней раньше. Рекомендую!

Что важно - утилита следует принципу единой ответственности, поэтому за установку JDK она не отвечает.
Но для этого есть другая утилита - sdkman
Как всегда статья https://www.baeldung.com/java-sdkman-intro
Да, JDK можно ставить любым менеджером пакетов или даже через IDEA.
Но у sdkman очень хороший выбор jdk https://sdkman.io/jdks и не только jdk https://sdkman.io/sdks
И тоже есть поддержка всех 3 основных ОС.

#java #jdk #tools

Обработка ошибок - не только Java

Как справедливо заметил @ort_gorthaur в комментах к посту об обработке исключений в Java https://t.me/javaKotlinDevOps/440
в других языках есть интересные варианты для обработки исключений.

Try в Scala
https://www.baeldung.com/scala/exception-handling

def trySuccessFailure(a: Int, b: Int): Try[Int] = Try {
Calculator.sum(a,b)
}

val result = trySuccessFailure(-1,-2)
result match {
case Failure(e) => assert(e.isInstanceOf[NegativeNumberException])
case Success(_) => fail("Should fail!")
}

Целых два варианта в Kotlin:

Try
https://www.javacodegeeks.com/2017/12/kotlin-try-type-functional-exception-handling.html

fun divideFn(dividend: String, divisor: String): Try<Int> {
val num = Try { dividend.toInt() }
val denom = Try { divisor.toInt() }
return num.flatMap { n -> denom.map { d -> n / d } }
}

val result = divideFn("5t", "4")
when(result) {
is Success -> println("Got ${result.value}")
is Failure -> println("An error : ${result.e}")
}

и Result
https://www.baeldung.com/kotlin/result-class

fun divide(a: Int, b: Int): Result {
return runCatching {
a / b
}
}

val resultValid = divide(10, 2)
assertTrue(resultValid.isSuccess)
assertEquals(5, resultValid.getOrNull())

Тоже два варианта - Option и Result - в Rust
https://habr.com/ru/articles/270371/

fn extension_explicit(file_name: &str) -> Option<&str> {
match find(file_name, '.') {
None => None,
Some(i) => Some(&file_name[i+1..]),
}
}

fn double_number(number_str: &str) -> Result<i32, ParseIntError> {
match number_str.parse::<i32>() {
Ok(n) => Ok(2 * n),
Err(err) => Err(err),
}
}

Основные особенности у всех этих вариантов:
1) автоматическое оборачивание исключения в класс
2) сохранение информации об ошибке
3) сопоставление типа (class pattern matching)

Что интересно, class pattern matching появился в Java в виде JEP 406: Pattern Matching for switch, а значит можно реализовать что-то похожее. Например, вот так:
https://habr.com/ru/articles/721326/

#error_handling #null_safety #java #comparision #kotlin #scala #rust

AI на практике или учимся читать с помощью AI)

Вот есть неплохая статья - введение в тему работы с ElasticSearch и JPA на Java+Spring https://habr.com/ru/companies/rostelecom/articles/851658/
Всем она хороша, кроме одного - 1700 строк, 120 кб текста, время для чтения - 41 минута. И как нетрудно догадаться - статья покрывает все основные темы по поиску с помощью Elasticsearch, но там прям много воды. Может автору за символы платят, хз)
Но повторюсь по сути все ок.
И тут казалось бы - вот звездный час AI. Тем более они теперь с интернетом дружат.

Скормил статью разным AI чатам, попросил сократить, сохранив код, основные классификации и описания атрибутов.

Итоги такие:

0) вне конкурса - пересказ в браузере Яндекс. Сокращает - отлично, но очень тезисно получается, ничего не понятно. Незачет

1) YaGPT - сказал, что не умеет, отправил на внешние сайты. Незачет

2) DeepSeek - полное фиаско. Во-первых забавный факт - когда я забыл отжать галочку: "искать в вебе" - модель стала пересказывать какую-то левую статью про работу с LLM. Включил галочку - модель увидела в ссылке слово rostelecom и стала пересказывать тарифы оператора. Ок, включаю режим рассуждений. Снова мимо, причем с дико странной формулировкой: "Мы не можем напрямую загрузить и обработать веб-страницу, но я могу вспомнить или найти ключевые моменты статьи, основываясь на ее содержании, если я с ней знаком." И далее снова левая статья и ее пересказ. В общем No comments, не пересказ - не конек DeepSeek

3) GigaChat - пересказал всю статью, сильно лучше Яндекс браузера, но потом пошли глюки. В первой версии пересказа был только код, почти без текста. Непонятно. Попросил добавить текста - исчез весь код. Попросил совместить - начал придумывать какие-то левые классы, т.е. потерял контекст. Еще работает медленно. Незачет

4) Perplexity - в целом неплохо пересказал с первого раза. Но - потерял последнюю треть документа - похоже на оптимизацию. Добавил недостающее после указания конкретных глав. Если просишь добавить без конкретики какие главы пропущены - все равно пропускает. Причем чем больше просишь - тем компактнее становится итоговый текст, т.е. видно, что модель экономит контекст. Еще минусы:
а) переставляет местами главы, причем не релевантно смыслу.
б) оставляет мало текста, приходится просить добавлять текстовые описания для атрибутов и вариантов реализации

5) Mistral - примерно все тоже самое, только в первой версии пересказа вообще практически не было текста, только код. Хотя просил я другое. После просьбы добавить текста - добавил. В остальном работает также, как Perplexity, с теми же минусами

Вывод: похоже с первого раза выдать нормальный пересказ большой статьи современные LLM не могут. И это даже не книга. Причина в оптимизации из-за ограниченного контекста. Но в режиме переписки работать можно.

P.S. И статья на 120 кб - это конечно перебор) Я люблю читать - но все равно перебор)

#ai #llm #elasticsearch #java #spring

Давненько не писал про свои факапы.

Вспомнился один, древний. Когда давным-давно я работал в компании, где разработка была на Delphi. И уже тогда было понятно, что Delphi не жилец, и нужно переходить на другую платформу.
Ремарка - а Delphi то еще жив: https://habr.com/ru/articles/928810/ Может зря с него слезли?))))

Вводные следующие: небольшая компания, переход от коробочных решений к заказной разработке на основе свой платформы, CRM\MIS системы.

Так вот, на тот момент у нас было два пути - .NET и Java.
Из стека Microsoft уже использовался MS SQL Server, для хранения OLTP данных и OLAP кубов. Ну и Windows с Office само собой.
И надо сказать, что Microsoft тогда (и думаю до 2022 года) активно работала с мелким бизнесом. Несколько конференций в год, бесплатные лицензии для разработки. Прямо кейсы с CD дисками по почте присылали с новыми версиями ПО.
Они еще для Linux решение как раз в то время пилили, так что и этот потенциальный вопрос снимался.
И как язык C# был лучше Java, особенно если смотреть ее начальные версии. Он ведь как раз исходя из уроков Delphi и Java был создан бывшим архитектором Delphi. Java более менее его догоняет только сейчас.
И видимо по этой причине - знакомая компания, частично знакомый стек - я как лид разработки сильно топил за .NET.
Причем лично мне Microsoft ничего не предлагал - на всякий случай)
Сила бренда. Ну и возможно конференции)

В итоге после жарких баталий выбрали Java. По прошествии времени могу сказать - и правильно сделали.
И дело даже не в языке. Сравним https://www.tiobe.com/tiobe-index/java/ vs https://www.tiobe.com/tiobe-index/csharp/
Да, позиции Java выше, C# так и не обогнал Java. И уже не обгонит) Но тренды у обоих языков не очень не очень.

Дело в vendor lock. Все-таки большинство компонентов от Microsoft - коммерческие. VS Code из бесплатных приходит на ум. Завязка на экосистему Windows велика, а эта экосистема больше клиентская, чем серверная. Сообщество разработчиков меньше. Не сравнивал количество библиотек, но почему-то уверен, что для Java их сильно больше.

Ну и все мы живем в мире победившего open source. Сервера приложений, ESB, Windows на серверах ушли. В области SQL хранилищ - Oracle и MSSQL пока держаться, но их теснят. В noSQL практически все open source. CI\CD - тоже. Вот разве что IntelliJ IDEA остается вне конкуренции. Eclipse и NetBeans не смогли, а наследники IDEA вряд ли станут open source.

Вывод философский: иногда стоит отказаться от привычных инструментов и шагнуть в неизведанное. Предварительно прикинув все плюсы и минусы, конечно. Оно может стать мейнстримом)

#fuckups #java #dotnet #delphi

Хочу порекомендовать попробовать такую фичу IDEA, как Kotlin Notebook.

Это конечно заимствование из ML и Python. Суть на картинке выше, но я дам краткое описание.

У нас есть один файл, который содержит как куски кода, так и текст с картинками в формате Markdown. Куски кода (snippet) можно исполнять прямо в файле, т.е. output появляется под кодом. Исполнять можно как сразу все - не интересно - так и по очереди. Результат исполнения сохраняется в контексте. Т.е. если в первом snippet-е объявили функцию, вызвали его, то во-втором можно ее использовать. Она даже красным перестает в этот момент светится. Т.к. autocomplete, подсказки IDE, документация - все работает.
Как по мне - удобная штука для разработки и отладки алгоритмов. Да, их в энтрепрайзе мало, но они есть)
Почему удобная - рядом и аналитика, и код.

Создать новый Notebook можно в Kotlin или Java проекте через меню New.

P.S. Для Java такое можно сделать - с помощью того же jshell. Но IDEA пока не умеет.

P.P.S Да, как и всегда (почти) в мире Java - инициализация ноутбука долгая)))

#kotlin #java #idea

Java vs Python, часть не помню какая)

Я уже делал несколько постов про то, как инструменты, исходно появившиеся в экосистеме Python, мигрируют в Java.
Причина я думаю понятна - большое число Java программистов, развитая экосистема.

Вот еще пример.

Важной частью Data Science является веб скрапинг (Web Scraping) - обход сайтов в сети интернет и получение из них определенного рода данных. И если вбить эти два слова "веб скрапинг" в поиск - он сразу подставит python)
Вот типичная статья из выдачи Яндекса https://habr.com/ru/companies/ruvds/articles/796885/
Основные python инструменты оттуда - BeautifulSoup, Scrapy, Selenium, lxml, pyquery

А что есть в Java? Есть ли что-то?)

BeautifulSoup - собственно парсинг страниц сайтов. Аналог в Java - jSoup https://www.baeldung.com/java-with-jsoup
Scrapy - тоже парсинг, но с многопоточкой, работой с сессией, куками. Т.е. для массового скрейпинга и работы со сложными сайтами. В Java - Webmagic https://www.baeldung.com/java-webmagic-web-crawler Возможностей поменьше, но инструмент в наличии
Selenium - не зависит от языка, вообще говоря написан на Java. В интеграционных тестах на Java я его еще лет 15 назад использовал.
lxml - быстрый парсер xml\html. Вообще у Java большой выбор парсеров: DOM, SAX, Stax. Но тут речь про работу с HTML, а HTML - это конечно подмножество XML, но, как правило - XML с ошибками. Зато в Java есть библиотечка TagSoup, цитата: "SAX-compliant parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild".
pyquery - работа с HTML в стиле jquery. Вот тут аналога не нашел, но, кажется, не критично.

Итого - экосистемы не изолированы, хорошие идеи перетекают из одной в другую. Java хоронить рано)

#java #python #data_science