Java: fill the gaps

​Теперь заменим for на forEach. Сколько элементов выведется в консоль?

​Сколько элементов выведется в консоль?

Почему в java нет Elvis оператора?

Элвис оператор ?: — популярная конструкция, которая используется в Groovy, Kotlin, C# и других языках, но не в java. В этом посте мы обсудим, почему так получилось и чем java отличается от Kotlin.

Часть 1: обзор операторов

Элвис оператор ?: используется следующим образом:

String src = …
String x = src ?: "default";

▫️Если

src равен null, то x = "default"
▫️Если src НЕ равен null, то x = src

По сути это сокращённая форма тернарного оператора:

String x = src==null ? src : "default"

Есть два оператора, которые похожи на элвис:
🔸 ?. (с точкой) — null-safe member selection operator

str?.toString()

= если str не равен null, то вызвать метод toString()

🔸 ?[] — null-safe array access

lines?[6]

= если массив lines существует, то прочитать 6 элемент

Все операторы неплохо соединяются между собой:

String aMember = g?.members?[0]?.name ?: "nobody";

Но элвис оператор это только ?:

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

На самом деле элвис оператор мог появиться уже в java 7. Пользователи java 5 называли элвис самой ожидаемой фичей. Но он не попал в итоговый релиз.

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

Часть 2: зачем нужен null

Цель элвис оператора — облегчить работу с null. Значение null в джава коде выступает в двух ролях:

1️⃣ Ожидаемое значение и часть бизнес-логики

Поле необязательное или ещё не готово. Разработчик знает об этом заранее и учитывает в коде.

Элвис оператор прекрасно подходит для этого сценария.

2️⃣ Индикатор ошибки

Что-то пошло не так: пропущен обязательный параметр, соединение с БД оборвалось, инициализация не завершилась. Получаем NullPointerException, разбираемся с причинами и устраняем ошибку.

Здесь элвис оператор замаскирует проблему и сделает только хуже. Ошибка прикроется значением по умолчанию и пройдёт мимо нас.

Часть 3: Kotlin

Котлин использует другой подход: по умолчанию переменные НЕ могут быть null. Свойство nullability задаётся явно — через вопросик:

var str: String? = "abc"

Все null значения под чётким контролем. Поэтому элвис оператор не скрывает ошибок, а помогает писать лаконичный код. Захотели nullability — чётко это обозначили. Хотим избавиться от этого свойства — используем элвис оператор.

Часть 4: Optional

В java 8 появился способ явно указать, что значение может быть пустым — класс Optional. Метод orElse выполняет функции элвис оператора: если внутри Optional ничего нет, то возвращается значение внутри orElse.

Итог

Во времена java 5 ситуация была сложной: null мог означать и ошибку, и нормальное значение. Чтобы не провоцировать скрытые ошибки, комьюнити отклонило добавление элвис оператора.

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

Тест на бюрократию

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

Курс можно было оплатить со стороны работодателя, но в итоге сорвалось 4 заявки: за 2 недели процесс согласования даже не продвинулся. А где-то мы списались с HR и за один(!) день закончили весь процесс.

Откуда вообще берётся бюрократия?

Уровень бюрократии не всегда связан с размером компании и численностью сотрудников. Истоки бюрократии хорошо описаны в книге "Good to Great":

Задача бюрократии — компенсировать отсутствие компетентности и дисцип­лины; такая проблема не возникает, если с самого начала правильно подобраны кадры. Большинство компаний создают свои бюрократические порядки, чтобы управлять небольшим процентом «неправильных» людей на корабле. Это в свою очередь заставляет лучших специалистов уходить. Увеличивается процент посредственных специалистов, что опять-таки приводит к необходимости создания ещё более жесткой бюрократии, чтобы компенсировать некомпетентность и отсутствие дисциплины, это ещё больше отталкивает лучших и т.д.

По мне слишком категорично, но доля правды есть.

Как оценить уровень бюрократии уже на собеседовании?

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

Чтобы примерно оценить бюрократический накал, спросите на собеседовании - что нужно сделать, чтобы пройти обучение или поехать на конференцию?

В бюрократических компаниях вам придется:
😐 Писать заявки
😒 Вписаться в лист ожидания где-то в недрах конфлюенс
😠 Обосновать потребность
😤 Самостоятельно следить за процессом
😡 Заключить договор, по которому вы оплатите часть стоимости, если уволитесь в ближайшие два года

Если от вопроса начнут уходить - это плохой знак. В хорошей компании от вас требуется 1-2 пункта. Идеально, если вы просто обращаетесь к специальному человеку, который уведомит вас о результатах в разумные сроки.

Масштабирование: основные типы

Что такое масштабирование? Какие виды вы знаете? - популярные вопросы на собеседованиях на позицию мидл и выше.

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

Иногда достаточно просто поменять код. Например, добавить кэш и снизить нагрузку на БД. В итоге сервис обработает в 10 раз больше запросов, и этого улучшения хватит на несколько лет. Но это не масштабирование, а оптимизация.

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

На самом верхнем уровне масштабирование делится на горизонтальное и вертикальное.

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

При горизонтальном нагрузка распределяется на несколько машин
✅ Отказ одного экземпляра не так страшен
✅ Пределы масштабирования гораздо шире
❌ Нужна инфраструктура для поддержки

В книжке Art of Scalability приводится концепт scale cube и три вектора горизонтального масштабирования:

🔸Horizontal duplication: несколько копий одного сервиса

✅ Простая реализация, нам нужен только балансировщик
❌ Запутанный код
❌ Тяжело обновлять версию сервиса
❌ Большие и перегруженные кэши

🔸Functional decomposition: делим монолит на микросервисы

Каждый сервис отвечает за небольшой функционал
✅ Простой и понятный код каждого сервиса
✅ Более специфичные и эффективные кэши
❌ Поделить монолит на отдельные сервисы и наладить общение между ними - чудовищно непросто
❌ Сложная инфраструктура

🔸Data partitioning или шардирование

Сервисы одни и те же, но каждый экземпляр работает на ограниченном количестве данных и своём экземпляре БД
✅ Отказы БД менее критичны
✅ Кэширование работает отлично
❌ Нужен компонент для перенаправления запросов
❌ Сложная логика работы с данными

На практике три подхода комбинируются в разных пропорциях.

IDEA: магия вне Хорвартса

Обычно я пишу о полезных фичах IDEA, которые помогают писать код быстрее и проще.

Но не сегодня. Сегодня расскажу о фиче, которая впечатлит ваших коллег.

Чтобы они такие: "вау, как ты это делаешь???", а вы так загадочно улыбаетесь.

Отлично подойдёт для обсуждения кода при личном общении и при демонстрации экрана на онлайн-встречах.

Как вставить один и тот же код в несколько мест? Обычные разработчики использую Ctrl+C и Ctrl+V, а настоящие шоумены - мультикаретки.

🔸 Добавляете каретку через Shift + Alt + Левый клик
🔸 Начинаете печатать

Вместо клика можно выделить часть текста и одновременно работать с несколькими фрагментами кода.

Чтобы вернуться в нормальный мир с одной кареткой, нажмите Esc.

Выглядит как магия, честное слово🔮

Вам в какую очередь?

В пакете java.util.concurrent доступно 7 очередей. Самые простые из них это

🔸 ArrayBlockingQueue
🔸 LinkedBlockingQueue
🔸 ConcurrentLinkedQueue

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

Часть 1: внутреннее устройство

По названию класса легко предположить, что одна реализация сделана на основе массива, а две - с помощью связного списка.

Что это даёт? По сути - ничего.
Вспомним 2 списка с похожим строением - ArrayList и LinkedList. В первом легко искать элемент по индексу, во втором - вставлять и удалять элемент из середины списка.
Для очереди это не важно, потому что нас интересует только работа с началом и концом очереди.

Часть 2: механизм синхронизации

А здесь уже интереснее:
🔹 ArrayBQ использует один ReentrantLock
🔹 LinkedBQ - два ReentrantLock: один для начала очереди, другой - для конца
🔹 ConcurrentLQ использует CAS операции для обновления крайних элементов

Давайте попарно сравним их между собой

▪️ArrayBQ и LinkedBQ

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

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

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

▪️LinkedBQ и ConcurrentLQ

Допустим, наша очередь никогда не пустует. Что лучше - два ReentrantLock или две CAS операции?

Здесь разница в методах, которые нам нужны.

CAS операции обновляют только сами элементы - начало и конец очереди.

ReentrantLock ограждает критическую секцию, внутри которой
▫️ Проверяется текущий размер и сама возможность добавить в очередь
▫️ Обновляется начало или конец очереди
▫️ Уведомляются потоки, которые, возможно ждут на другом конце очереди

Добавление и удаление в ConcurrentLQ происходит очень быстро. Если нужны дополнительные опции - фиксированный размер, блокирующие вызовы, то лучше подойдёт LinkedBQ.

Поэтому критерий выбора очереди №2: необходимые методы и ограничения на размер

Mutation testing: тесты на тесты

Фраза "нужны тесты на тесты" на проектах встречается часто. Звучит как шутка, но проблема за этим стоит серьёзная.

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

Test Coverage - сомнительная метрика. Высокий test coverage означает только, что в тестах участвует много кода.

В этом посте я расскажу о mutation testing. В чём суть, возможные минусы и как использовать подход mutation testing уже сейчас.

Идея

Фреймворк делает небольшое изменение в коде и запускает тесты. Тесты упали - значит кейс проверяется. Тесты прошли - значит тестов не хватает.

Пример: тестируется метод

return m > 10;

Написали для него тесты:
▫️m = 0, ожидаем false
▫️m = 100, ожидаем true

Фреймворк поменяет код на m ≥ 10, и ни один тест не упадёт. Значит, текущих тестов недостаточно, нужно проверить условие m = 10

Практика

Для JVM языков по факту есть только один фреймворк Pitest с двумя опциями - Gregor and Descartes.

Как работает:
1️⃣ Запускает тесты и анализирует test coverage. Если код не покрыт тестами, то нет смысла мутировать его.

2️⃣ Составляет список мутаций. Здесь два варианта:
🔸 Gregor тестирует по максимуму, в том числе геттеры и сеттеры
🔸 Descartes использует меньше вариаций, но работает быстрее

3️⃣ Для каждого пункта фреймворк меняет байт-код и запускает тесты. Все изменения, для которых тесты прошли, попадают в итоговый репорт

Минусы

❌ Проверяются только несложные изменения бизнес-логики

❌ Долго выполняется: от 10 минут до 6 часов. Для популярных библиотек результаты такие

❌ Сложно читать результаты и понять, каких тестов не хватает. Связано это с тем, что фреймворк работает не с исходным кодом, а с байт-кодом

❌ Gregor плохо совместим с Kotlin и проверяет конструкции, недопустимые на уровне языка. Приходится либо терпеть множество предупреждений, либо исключать некоторые проверки и рисковать бизнес-логикой. Либо использовать Descartes

❌ Слабо развивается и выглядит как pet project

❌ Непонятно как встроить в CI. Так как возможны ложноположительные результаты, репорты нужно проверять вручную. Можно оставить как необязательную опцию для самых мнительных, но проверка занимает много времени и вряд ли будет востребована

Итог: идея интересная и перспективная, но слабо развивается на практике.

Хозяйке на заметку

Подход mutation testing подойдёт для проверки тестов сложного или критичного участка кода:

▫️Поменяйте условие
▫️Верните константу в метод
▫️Удалите тело в void методе
▫️Поменяйте методы местами
▫️Уберите инкремент
▫️Верните null
▫️Поменяйте бизнес-логику

И запустите тесты. Если падают - значит код протестирован хорошо. Если нет - допишите тесты. Главное - вернуть потом изменения обратно🙂

JVM Report 2020

Израильская компания Snyk каждый год опрашивает разработчиков о проектах и технологиях. В этом году в выборке 60% участников из Европы, 19% из США, на Россию и Азию пришлось 12%. Хороший шанс посмотреть, что там у других и на картину в целом

Полный отчёт доступен тут, а я расскажу самое интересное

1️⃣ Самый популярный JVM язык:
Однозначно, java. Используется на 91% проектов

31% используют в проектах несколько языков. Среди них:
17% Kotlin
13% Groovy
10% Scala
8,4% Closure

2️⃣ Версия java в продакшене:
61% Java 11
59% Java 8
11% Java 15

40% опрошенных используют несколько версий
30% используют Java 8 и Java 11

3️⃣ Какая JDK используется в продакшене:
44% AdoptOpenJDK
28% Oracle OpenJDK
23% Oracle JDK
15% Azul Zulu

37% участников используют 2 JDK, а 12.5% - три и больше.

4️⃣ Как собирается приложение:
76% Maven
38% Gradle
12% Ant

5️⃣ Основной фреймворк разработки:
58% Spring Boot
29% Spring MVC
24% Java EE
13% Jakarta EE
11% Quarkus
5% Micronaut

16% не пользуются фреймворками вообще😱

6️⃣ Самая популярная IDE:
72% IDEA
24% Eclipse
23% Visual Studio Code (2% в прошлом году)
13% Apache NetBeans (1% в прошлом году)

51% ответили, что пользуются несколькими IDE

По сравнению с прошлым годом Java 11 используется на 40% чаще, а IDEA и Kotlin уверенно укрепляют позиции💪

Generics, часть 2: вопросики

В этой части разберём wildcards, и как дженерики работают с иерархиями.

Начнём с ответа на вопрос перед постом. Компилятор выдаст ошибку.

Почему так?

Пойдём от обратного и представим, что метод принимает List<Child>.

Внутри метода мы работаем со ссылкой на List<Parent>, значит в список можно добавить объект Parent. Если метод примет List<Child>, значит List<Child> тоже принимает объекты Parent. Что противоречит контракту, поэтому List<Child> никак не связан с List<Parent>.

Здесь разработчики дженериков учли неудачный опыт с массивами. Для массивов возможна такая ситуация:
🔸 Создаём переменную arr с массивом Parent:

Parent[] arr;

🔸 Присваиваем массив Child:

arr = new Child[2];

🔸 Добавляем в arr экземпляры Child и Parent:

arr[0] = new Child();
arr[1] = new Parent();

Вторая строка в рантайме бросит ArrayStoreException. Дженерики обрабатываются при компиляции, поэтому ошибок на этапе выполнения нет.

Wildcards

Для ситуаций, когда мы точно-точно не будем менять список, и нам только посмотреть, можно использовать wildcards:

void print(List<?> list)

Теперь метод принимает списки любых типов. Конкретный тип неизвестен, поэтому доступны только методы класса Object. Можно получить размер списка или вызвать для элементов toString.

❓Чем List<?> отличается от List?

В List<?> компилятор не даст ничего добавить, а для List ограничений нет.

❓Как вызвать нужные методы для List<?>?

Тип в списке можно уточнить:

void print(List<? extends Parent> list)

Теперь метод принимает только List<Parent> и List<Child>, плюс есть доступ к методам Parent. Но менять список всё ещё нельзя.

Буквы и вопросики

Есть два способа ограничить типы списков:

▫️ <T extends Parent> void test(List<T> list)
▫️ void test(List<? extends Parent> list)

Чем они отличаются?

T - это конкретный тип элементов списка, поэтому в список можно добавить объекты типа Т. В листе с вопросиком конкретный тип НЕ известен, и компилятор НЕ даст добавить новые элементы.

extends и super

В иерархии Object - Parent - Child можно ограничить типы с разных сторон.

extends - ограничение иерархии "сверху"
? extends Parent: допустимы Parent, Child и наследники Child

super - ограничение типов "снизу"
? super Parent принимает Parent и родителей Parent вплоть до Object

​Какой результат выполнения этого кода?

Generics, часть 1: история и корпоративные ценности

Вернёмся в 1998 год.

В java 1.2 появились интерфейсы Map, Set, List и основные реализации. В те времена они хранили только объекты:

List values = new ArrayList()

Чтобы нормально работать, приходилось использовать явное приведение:

values.add("value");
String s = (String) values.get(0);

Главная проблема с коллекциями тех лет - type loss, потеря типа при компиляции и написании кода:
❌ Можно запросто получить ClassCastException
❌ Надо помнить тип объектов
❌ Ошибки возникают только в рантайме

В java 5 появилась возможность указать тип через дженерики:

List<String> values = new ArrayList<String>();
values.add("p");
String v = values.get(0);

✅ Удобно пользоваться
✅ Хорошо читается
✅ Компилятор проверяет типы

Как реализованы дженерики?

Примерим на себя должность архитектора java и прикинем, что можно сделать с ArrayList<T>:

1️⃣ Скомпилировать в класс с типом String
Все T заменяем на String:

void add(String str)
String get(int index)

В итоге создаём отдельный класс для каждого типа данных.

2️⃣ Добавить в JVM параметризованный тип

<T> остаётся на уровне байт-кода и определяется для каждого объекта в рантайме.

3️⃣ Оставить на уровне JVM работу с объектами. Проверить все типы во время компиляции и привести один к другому там, где нужно.
Получаем один ArrayList.class и множество дополнительных конструкций по всему коду.

Для ArrayList<String> программист напишет:

String value = list.get(0)

Компилятор преобразует это в

String value = (String) list.get(0);

🤔Все варианты адекватные и имеют право на жизнь. Что же выбрать?

Почти в каждом IT офисе на стенах висят слоганы и ценности компании. Что-то про качество работы, развитие сотрудников, гибкость и довольных клиентов. Из этого получается классный корпоративный мерч.

Ценности нормального человека определяют стратегию и дают ориентир для решения сложных ситуаций. "Ценности" java явно нигде не определены, но направление работы задано чётко. Например, кроссплатформенность и слоган Write Once, Run Anywhere заставляют разработчиков JDK поддерживать фичи даже для древних процессоров.

Бинарная совместимость - ещё один ориентир java. Поэтому для дженериков используется третий вариант: компилятор добавляет необходимые приведения типов в код и стирает информацию о дженериках. И код на java 5 теперь совместим с предыдущими версиями.

Ответ на вопрос перед постом

В консоли напечатаются оба значения. У списка tmp тип не задан, поэтому компилятор не мешает добавлять строки и передавать объекты в метод println.

Если в println передать список intList.get(0), где тип указан явно, то мы получим ошибку компиляции.

​Какой результат выполнения этого кода?

Почему на канале так много Java Core? Потому что это база для ежедневной работы, которую хорошо знать вдоль и поперёк. Но лично мой интерес лежит в другом. Мне нравится разбирать дизайн и разбираться, почему сделано так, а не иначе.

Тема этой недели - дженерики.
Часть 1: посмотрим реализацию в JVM
Часть 2: углубимся в wildcards и работу с подтипами

Ресурсы, идиома RAII и Java 9

Разработка - сложная штука c множеством идей и концептов. В этом посте я расскажу об идиоме RAII, разнице при работе с ресурсами в java и C++, блоке try-with-resources и изменениях java 9.

Начнём с основ. Ресурс - это сущность, для которой нужен эксклюзивный доступ. Их количество ограничено. Большинство ресурсов находятся за пределами JVM: файлы, соединения с БД, сокеты и т.д

Для корректной работы только один поток должен работать с ресурсом. Для этого нужно принять дополнительные меры. Обозначим их как "открыть" и "закрыть" ресурс:
🔸Открыть = получить эксклюзивный доступ.
🔸Закрыть = закончить работу. Теперь другой поток может работать с ресурсом.

Такой вот нехитрый жизненный цикл(ЖЦ).

RAII
или Resource Acquisition Is Initialization - одна из техник по работе с ресурсами. Другое название: SBRM - Scope-Bound Resource Management.

Суть: ассоциируем ресурс с объектом. Тогда ЖЦ ресурса совпадает с ЖЦ объекта. В идеале это выглядит так:

public void do() {
  File f=new File("t.txt"); 
  // Создаём объект File, ресурс "t.txt" теперь наш
  // что-то делаем
}
// вышли из метода: объект f уже не нужен, ресурс "t.txt" освобождается

RAII легко реализовать в С++. В конструкторе пишем логику "открытия" ресурса, а в деструкторе - "закрытия". Конструктор и деструктор явно прописываются, поэтому ЖЦ объекта и ресурса под контролем.

В java так не получится. Деструктор выполнится неизвестно когда, а ресурс - штука ценная. Поэтому в java нужно явно вызвать метод закрытия. В стандартных библиотеках это close().

В java 7 появилась специальная конструкция для ресурсов:

try (PrintWriter writer = new PrintWriter(…)) {
   // что-то делаем
}

Ресурс реализует интерфейс AutoCloseable, и после завершения блока для него вызовется close(). try-with-resources считается java реализацией RAII.

Но такой формат не идеален. Внутри try всегда определяется новый объект. Когда ресурсов два и больше, код становится громоздким:

try (DatagramChannel udpServer = …;
     Selector selector = …) {
  // …
}

В java 9 в блок try можно передать переменные:

DatagramChannel udpServer = …;
Selector selector = …;

try (udpServer;selector) {
    // …
}

С одной стороны это удобно. Код выглядит приятно.

С другой - после try остаются переменные с закрытыми ресурсами. Теперь нельзя сказать, что java реализует RAII.

Ну и ладно, никто не расстроился🙂 Языки разные, и классно замечать, как по-разному в них реализуются идеи, и как они меняются с течением времени.