🖥Заменят ли потоки данных циклы в Java?

Выпуск версии Java 8 стал знаменательным событием в истории Java. В нем были представлены потоки данных (англ. Streams) и лямбда-выражения, которые сейчас широко применяются. Если вы не знакомы с потоками данных или никогда не слышали о них, то ничего страшного. В большинстве случаев можно обойтись без них, задействуя циклы.

И зачем тогда, спрашивается, нужны потоки данных? Есть ли у них преимущества перед циклами? Могут ли они их заменить? В статье мы изучим соответствующий код, сравним производительность и посмотрим, смогут ли потоки данных стать полноценной заменой циклов.

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

Список имен элементов с заданным типом
Допустим, у нас есть список элементов, и нужно получить список имен элементов с заданным типом. Используя циклы, пишем следующий код:

List<String> getItemNamesOfType(List<Item> items, Item.Type type) {
List<String> itemNames = new ArrayList<>();
for (Item item : items) {
if (item.type() == type) {
itemNames.add(item.name());
}
}
return itemNames;
}
Читаем код и видим, что требуется создать новый ArrayList и в каждом цикле выполнять проверку типов и вызов add(). Теперь посмотрим, как с этой же задачей справляется поток данных:

List<String> getItemNamesOfTypeStream(List<Item> items, Item.Type type) {
return items.stream()
.filter(item -> item.type() == type)
.map(item -> item.name())
.toList();
}
С помощью лямбда-выражения сразу становится понятно, что мы сначала выбираем элементы с заданным типом, а затем получаем список имен отфильтрованных элементов. В таком варианте кода построчный поток хорошо согласуется с логическим потоком.

Генерация случайного списка
Переходим к другому примеру. В следующих разделах мы рассмотрим ключевые методы потоков данных и сравним время их выполнения с циклами. Для этого потребуется случайный список Item. Ниже представлен фрагмент кода со статическим методом, который генерирует такой список:

public record Item(Type type, String name) {
public enum Type {
WEAPON, ARMOR, HELMET, GLOVES, BOOTS,
}

private static final Random random = new Random();
private static final String[] NAMES = {
"beginner",
"knight",
"king",
"dragon",
};

public static Item random() {
return new Item(
Type.values()[random.nextInt(Type.values().length)],
NAMES[random.nextInt(NAMES.length)]);
}
}
Теперь создаем случайный список Item с помощью циклов. Пишем следующий код:

List<Item> items = new ArrayList<>(100);
for (int i = 0; i < 100; i++) {
items.add(Item.random());
}
Код с потоками данных выглядит следующим образом:

List<Item> items = Stream.generate(Item::random).limit(length).toList();
Превосходный и легко читаемый код. Более того, List, возвращаемый методом toList(), представляет собой неизменяемый список. Так что вы можете пользоваться неизменяемостью List и размещать его в любых местах кода, не беспокоясь о побочных эффектах. Такой подход снижает вероятность появления ошибок в коде и облегчает его понимание.

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

allMatch();
anyMatch();
count();
filter();
findFirst();
forEach();
map();
reduce();
sorted();
limit()

и многие другие методы, с описанием которых можно ознакомиться по ссылке на документацию Stream Javadoc.
Производительность
При обычных обстоятельствах потоки данных ведут себя как циклы и практически не влияют на время выполнения. Сравним основные варианты поведения потоков с реализацией циклов.

📌Читать дальше

@javatg

🖥 10 полезных репозиториев GitHub для каждого Java-разработчика

1. JavaШаблоны проектирвоания
2. Cобеседования
3. Алгоритмы
4. Проекты
5. Awesome Java
6. Baeldung Tutorials
7. JHipster
8. Spring Framework
9. Spring Boot Tutorials by Java Guides
10. сracking the Coding Interview in Java

@javatg

🍀 NetMock: простой подход к тестированию HTTP-запросов в Java, Android и Kotlin Multiplatform

NetMock — это мощная и удобная библиотека, которая упрощает имитацию HTTP-запросов и ответов.

Улучшение стратегии тестирования HTTP-кода

• Подход предполагает изолирование HTTP-кода в отдельные компоненты, что позволяет проводить независимое тестирование остальной системы.
• Несмотря на то, что данный подход упрощает репозитории и тестовые классы, он часто пренебрегает тестированием самого HTTP-кода из-за сопутствующих сложностей.
• В результате возникает потребность проверять важнейшую логику, связанную с HTTP-запросами и парсингом JSON.

Данная проблема прослеживается в проектах, задействующих Retrofit.

Эта библиотека абстрагирует HTTP-логику посредством интерфейсов. Рассмотрим следующий фрагмент кода:
interface GitHubService {
@GET("users/{user}/repos")
suspend fun listRepos(@Path("user") user: String): List<RepoDto>
}

class GitHubRepositoryImpl(
private val githubService: GitHubService,
private val repoMapper: RepoMapper
): GitHubRepository {
override suspend fun listRepos(user: String): List<Repo> {
val repoDtos = githubService.listRepos(user)
return repoMapper.map(repoDtos)
}
}

Хотя этот подход упрощает репозитории и тестовые классы, он часто пренебрегает важными тестами для HTTP-логики. Кроме того, существует вероятность создания ненужных компонентов исключительно для упрощения модульного тестирования репозиториев.

Цель модульного тестирования — предотвращать и выявлять ошибки разработчиков, тем самым гарантируя правильную работу кода. Без надлежащих тестов даже простые ошибки, такие как изменение пути с users/{user}/repos на user/{user}/repos или переименование поля в RepoDto, могут остаться незамеченными, что неприемлемо в профессиональном проекте.

Я вовсе не критикую Retrofit. Наоборот, считаю ее отличной и удобочитаемой библиотекой.

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

Я просто указываю на недостатки стратегии тестирования, которую наблюдал во многих проектах. Она вынуждает больше внимания уделять комплексному тестированию HTTP-кода, вследствие чего потенциальные проблемы остаются незамеченными. Акцентируя данную проблему, призываю разработчиков с особой ответственностью подходить к тестированию HTTP-логики, тем самым обеспечивая общее качество и надежность проектов.

Имитация запросов и ответов с помощью NetMock
@Test
fun `your test`() = runTest {
val user = "some_user"
netMock.addMock(
request = {
method = Method.Get
requestUrl = "https://api.github.com/users/$user/repos"
},
response = {
code = 200
body = readFromResources("responses/repo_list.json")
}
)

val result = sut.listRepos(user)

//...
}

Для имитации запросов и ответов применяется простой API, предоставляемый NetMock.

Добавляя mock-объект в очередь ожидаемых запросов и ответов, вы можете перехватывать и контролировать поведение HTTP-взаимодействий во время тестирования.

Создание экземпляра NetMock

Читать

@javatg

⏱ Все что вам нужно знать о таймаутах

Зачем устанавливать таймауты

Давайте для начала ответим на простой вопрос: "Зачем устанавливать таймауты?". Успешный ответ сервиса, даже если он занимает много времени, лучше, чем ошибка закрытия соединения по таймауту.
▪️Хм... не всегда, давайте разбираться.

Прежде всего если сервис не отвечает или отвечает слишком медленно, никто не будет ждать. Вместо того чтобы испытывать терпение ваших пользователей, следуйте принципу fail-fast. Позвольте вашим клиентам повторить запрос или обработать ошибку на их стороне. Когда возможно, возвращайте fallback значение.

Другой важный аспект - это утилизация ресурсов. В то время пока клиент ожидает ответ, различные ресурсы используются на стороне сервиса: треды, http коннекшены, коннекшены базы данных и т.д. Даже если клиент закроет соединение, без правильной конфигурации таймаутов запрос будет обрабатываться на сервере, а это значит что ресурсы будут заняты.

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

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

Но для продакшен сервисов - это недопустимо. Это может быть даже опасным. Например, в нативном java HttClient connection/request таймауты отключены, я не думаю что это в рамках вашего SLA :)

📌 Продолжение

@javatg

🖥 Android Interview Questions

Очень полезная шпаргалка для собеседования по Android - Вопросы для собеседования по Android

▪Github

@javatg

🔋Основы реактивного программирования

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

Основное назначение Reactor — предоставление набора инструментов и абстракций для создания реактивных приложений. Reactor предлагает набор основных компонентов, таких как Flux и Mono, которые представляют собой потоки данных и событий. Эти компоненты могут быть объединены и преобразованы с помощью набора операторов, таких как map, filter и reduce, для создания сложных потоков данных.

Сравнение Mono и Flux
Как уже говорилось, реактивное программирование работает по модели “издатель-подписчик”. И Mono, и Flux предоставляют абстракцию для публикации событий.

Разница между ними заключается в том, что Mono может публиковать только одно событие за раз, а Flux — несколько событий за раз. Поэтому когда нужно публиковать только одно событие, выбирают Mono, а когда нужно публиковать несколько событий — Flux.

Теперь приведу небольшой пример, поясняющий каждую упоминаемую ранее концепцию.

Демо
Все начинается с того, что издатель выдает событие для потребителя.

Как и java-потоки, Flux и Mono придерживаются ленивого выполнения, т.е. значение выражения не обрабатывается до тех пор, пока в нем нет необходимости.

Начнем с создания простого Flux.
Flux<Integer> flux = Flux.just(1, 2, 3, 4, 5);

Метод “just” позволяет создать Flux, если есть доступное значение. Это самый простой способ создания Flux. Несмотря на то что я привожу пример с Flux, шаги остаются такими же и для Mono. В Mono также используется метод “just” с той разницей, что Mono применяется только для одного элемента. Поэтому если задать несколько значений, то получим ошибку.
Flux<String> mappedFlux = flux.map(i -> "Number: " + i)
The above flux gets converted to
"Number: 1", "Number: 2", "Number: 3", "Number: 4", "Number: 5"

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

1. Map: преобразует каждый элемент, выдаваемый потоком данных, применяя к нему функцию.
2. Filter: фильтрует элементы, выдаваемые потоком данных, на основе предикатной функции.
3. Reduce: агрегирует элементы, выдаваемые потоком данных, в одно значение с помощью функции-аккумулятора.
4. Merge: объединяет несколько потоков данных в один.
5. Concat: конкатенирует нескольких потоков данных в один в определенном порядке.
6. FlatMap: преобразует каждый элемент, выдаваемый потоком данных, в другой поток данных, а затем сводит полученные потоки в один.
7. Zip: объединяет элементы, выдаваемые несколькими потоками данных, в один элемент с помощью функции-комбинатора.

Применим еще несколько операторов для пояснения их работы.
Flux<String> filteredFlux = mappedFlux.filter(s -> !s.endsWith("2") && !s.endsWith("4"));

Flux преобразуется в:
"Number: 1", "Number: 3", "Number: 5"

Теперь сведем Flux к одной строке.
Mono<String> reducedMono = filteredFlux.reduce("", (a, b) -> a+ ", " + b);

Flux преобразуется в:
"Number: 1, Number: 3, Number: 5"

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

*️⃣Следует отметить, что я добавил преобразованный вывод для пояснения, а на самом деле никаких вычислений не происходит. Как уже говорилось, Flux следует модели ленивого исполнения. Пока мы не подпишемся на поток событий, никаких вычислений не происходит. А когда подписываемся, получаем возможность контролировать то, что нужно сделать с полученным событием.

Чтобы упростить задачу и показать, как работает подписчик, просто выведу Flux.

📌Читать

@javatg

🖥 Новости Java

Spring Modulith 1.0 GA Released. Новый -релиз получила Spring Modulith — часть экосистемы Spring, призванная упростить построение модульных монолитов.

Announcing Testcontainers Desktop Free Application — свежий анонс утилиты, удобной для работы с тест-контейнерами. Из интересного — быстрое переключение между docker/colima/podman, возможность запуска контейнеров на фиксированных портах и их фриз на время дебага.

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

OpenAI выложила на Github OpenCopilot. OpenCopilot — это ИИ-помощник, способный интегрироваться в продукт. Он готов к встраиванию через базовые API и может вызывать эти API по необходимости. Модель OpenCopilot основана на обширной лингвистической базе и способна определить, требует ли запрос пользователя выполнения вызова к какой-либо конечной точке API.

Дмитрий Иванов, Андрей Кулешов — Пирамида потребностей Маслоу для Java/Kotlin-разработчика. Виде — это полноценная методичка, посвященная тому, как начать и развить свой open-source-проект. От стадии кодинга и до построения комьюнити — каждый шаг расписан детально, с приведением полезных инструментов и практик.

JDK 21 G1/Parallel/Serial GC changes — статья о том, как изменятся сборщики мусора в JDK 21, и о планах их развития. Основные изменения коснутся G1 GС:

@javatg

🖥Перестаём бояться генерировать байт-код

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

JVM устроена гораздо проще, чем CPU; она оперирует такими высокоуровневыми понятиями как классы, интерфейсы, методы, а не просто лопатит байты в памяти. В отличие от CPU, который легко уронить криво сгенерированным машинным кодом, JVM заботливо отверифицирует любой байт-код и в общем не даст выстрелить в ногу.

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

Весь приведённый код доступен в репозитории.



Задача
Я вдохновился книгой Бьёрна Страуструпа, по которой лет 20 назад изучал C++. В одной из первых глав в качестве задачи для введения в язык предлагается написать калькулятор выражений. Я же предлагаю не вычислять выражения, а генерировать байт-код, который вычисляет выражения.

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

public interface Expression {
double evaluate(Function<String, Double> inputs);
}
Выражения в списке разделены точкой с запятой (;), метод evaluate возвращает результат вычисления последнего из выражений. Выражения определим так:

Число (например, 2, 42, 3.14) — это выражение.
Идентификатор (например, foo, pi, myVar_1) — это выражение. Значение по-умолчанию для переменной вычисляется с помощью вызова inputs.apply(id).
Если A и B — выражения, то A + B, A - B, A * B, A / B, -A, (A) — так же выражения
Если A — это идентификатор, и B — это выражение, то A = B — так же выражение
Генерируем класс
Для начала напишем генератор класса, реализующего интерфейс Expression.

▪Читать дальше
▪Github

@javatg