Тагир Валеев (lany) и Барух Садогурский (jbaruch) собрали новую коллекцию Java-паззлеров и спешат ими поделиться.


В основе статьи – расшифровка их выступления на осенней конференции JPoint 2017. Она показывает, сколько загадок таит в себе Java 8 и едва замаячившая на горизонте Java 9. Все эти стримы, лямбды, монады, Optional-ы и CompletableFuture-ы были добавлены туда исключительно для того, чтобы нас запутать.

Все, о чем они рассказывают, должно работать на последней версии Java 8 и 9, соответственно. Мы проверили – вроде все по-честному: как написано, так себя и ведет.

На всякий случай пара слов об авторах, хотя мы думаем, вы их и так уже хорошо знаете: Барух занимается Developer Relations в компании JFrog, Тагир – разработчик IntelliJ IDEA и автор библиотеки StreamEx.

Java-паззлер №1: как прохакать банк

Для разминки задаем первый паззлер: неизвестные американские хакеры пытаются прохакать банк.



Мы тут в общем-то маппируем банковскую логику на Java Semaphore. В конструкторе Semaphore у нас будет начальный баланс. Мы начинаем в овердрафте -42 и дальше мы маппируем некоторые методы Semaphore на банковские методы. То есть drainPermits – это у нас будет «забрать все деньги из банка», а вот availablePermits – это будет «проверить баланс».

public class PerfectRobbery {
    	private Semaphore bankAccount = new Semaphore(-42);
    	public static void main(String[] args) {
            	PerfectRobbery perfectRobbery = new PerfectRobbery();
            	perfectRobbery.takeAllMoney();
            	perfectRobbery.checkBalance();
   	}
   	public void takeAllMoney(){
        bankAccount.drainPermits();
  	}
  	public void checkBalance(){
         System.out.println(bankAccount.availablePermits());
 	}
}

И дальше у нас будет некоторая логика. Мы создаем объект PerfectRobbery в классе PerfectRobbery и вызываем два метода: забрать все деньги из банка и проверить, что мы действительно забрали все деньги.

Как можно создать Semaphore с отрицательным начальным значением? Это прекрасный вопрос, потому что это первый вариант ответа. И кроме него, у меня есть еще три.

A. IllegalArgumentException – нельзя создавать семафор с негативным балансом;
B. UnsupportedOperationException – можно создать семафор с негативным балансом, но нельзя вызывать на нем drainPermits;
C. 0 – drainPermits при негативном балансе оставит ноль пермитов;
D. -42 — drainPermits при негативном балансе оставит столько же, сколько было, потому что сливать нечего.

Голосование в аудитории показало, что большинство – за вариант D, а правильный ответ – С.

В документации Java можно найти упоминание о том, что семафор может принимать негативное значение. Кроме этого, там написано, что drainPermits возвращает все available permits.



Сколько у нас доступно, когда у нас есть -42 пермита? У нас доступно 0, поэтому Сергей Курсенко открыл багу и сказал: ребята, что-то у вас какая-то ерунда. Drain available permits при -42 должен оставлять -42, потому что available permits 0. Когда мы сольем 0 из -42, будет -42.



Но не тут-то было, потому что в комменты пришел Даг Ли и сказал: «Я так хочу! И поэтому я «пофиксю это», добавив строчку в Javadoc».

Java-паззлер №2: синглтоны

Пойдем дальше. Маленький совет от нас: не создавайте синглтоны, лучше пейте синглтоны.



Давайте посмотрим Java 7. Вы можете создавать там пустые списки с помощью emptyList и пустые итераторы с помощью emptyIterator.

Collections.emptyList() == Collections.emptyList();
Collections.emptyIterator() == Collections.emptyIterator();

И вот вопрос: а синглтоны ли они? Всегда ли нам возвращается один и тот же объект? У нас есть четыре варианта ответа:

A. true/true – всегда возвращается;
B. true/false – синглтон — только список, а итератор каждый раз разный;
C. false/true – итератор – синглтон, а список каждый раз создается новый;
D. false/false – это вообще не синглтоны.

Голосование в аудитории показало, что большинство – за вариант B, а правильный ответ – A. Тут напрашивается вопрос: а где паззлер? Паззлер будет дальше.

Перейдем к Java 8. В ней появились новые методы, которые нам возвращают пустые штуки: сплиттераторы и стрим.

Spliterators.emptySpliterator() == Spliterators.emptySpliterator();
Stream.empty() == Stream.empty();

И давайте повторим вопрос для них:

A. true/true
B. true/false
C. false/true
D. false/false

Голосование в аудитории показало, что большинство – за вариант D, а правильный ответ – B. Сплиттератор может быть синглтоном, потому что у него нет состояния: пустой сплиттератор вы можете сколько угодно раз пытаться обойти, он скажет, что обойти нечего. Однако стрим имеет состояние, и оно состоит как минимум из двух вещей: во-первых, на стрим вы можете вешать closeHandler-ы. Представьте, что если бы это был синглтон, вы бы в одном месте повесили на него один хендлер, а в другом – другой, и неизвестно, что у вас после этого получится. Конечно, каждый пустой стрим должен быть свободный, независимый. Во-вторых, стрим должен быть использован только один раз. Если стрим используется повторно, то он определяет это и кидает IllegalStateException.

Java-паззлер №3: одинаковые списки

В следующем паззлере мы используем слово «одинаковые» в несколько странном смысле. Одинаковые – это такие же по состоянию внутренней структуры. Это не значит, что они равны по equals или у них hashcode одинаковый, и не значит, что они имеют отношение к проверке референсов.

Мы создаем массив из двух списков. В Java 8 появился метод setAll, который позволяет сразу его весь заполнить. Мы его заполняем с помощью конструктора ArrayList. Получим массив, состоящий из двух списков:

List[] twins = new List[2];
Arrays.setAll(twins, ArrayList::new);

Вопрос: какие списки там будут? Варианты ответа:

A. Одинаковые пустые списки
B. Одинаковые не пустые списки
C. Не одинаковые пустые списки
D. Не одинаковые не пустые списки

Голосование в аудитории показало, что большинство – за вариант A, а правильный ответ – C.

Во-первых, setAll принимает не supplier, а inputInt Function, которая ему на вход передается индекс массива и, соответственно, этот индекс массива аргументом. Он автоматически меппится на конструктор ArrayList не от пустого аргумента, а от initialCapacity. То есть этот индекс, который передается там, нигде не прописан и не виден. И это прямо какой-то Groovy: мы что-то пишем, и у нас что-то выполняется, а мы не знаем, что.



Кстати, мы можем вылететь на OutOfMemory благодаря этому. Если бы мы создали массив на 100 тысяч, у нас были бы списки, в которых внутри были бы предопределенные массивы тоже на 100 тысяч.

Java-паззлер №4: Single Abstract Method

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

public interface Сэм<T> {
       default void расширятьНато(String новаяСтрана) {
                  System.out.println(новаяСтрана); }
   	void расширятьНато(T songName);
   	void захватыватьНефть(T новаяСтрана);
   	void захватыватьНефть(String новаяСтрана);
}
@FunctionalInterface
public interface ДядяСэм extends Сэм<String> { }

Вот варианты ответов:

A. Что за ерунда?! ’Single’ означает один метод, не три!
B. Проблема с методом расширятьНато(T), если его убрать, все ОК
C. Проблема с методами захватыватьНефть, если убрать один, то все
будет ОК.
D. Все путем! Дубликаты схлопываются, и мы остаемся с одним захватыватьНефть.

Голосование в аудитории показало, что большинство – за вариант D, а правильный ответ – B. Дело в том, что метод, который не реализован (расширятьНато), не перекрывается дефолтной реализацией, и компилятор не может решить, что использовать. Это написано в документации: вы можете унаследовать из интерфейса несколько абстрактных методов с override-equivalent signatures. Когда мы определили, что Т – это стринг, два метода схлопнулись, это хорошо. Но если интерфейс наследует дефолтный метод, и его сигнатура override-equivalent абстрактному методу, это ошибка компиляции потому что возникает неоднозначность: хотим мы использовать дефолтную реализацию или нет.


Скриншот из Java Language Specification

Java-паззлер №5: Как хакнуть банк. Вторая версия

Весь банковский софт написан на Java. Альфа-банк – это Java, Deutsche Bank – это Java, Сбербанк – это Java. Все банки пишут на Java, значит, атака на Java, в ней много дыр, ее легко хакнуть, потом найти самые крупные счета и снять с них деньги.

Set<String> accounts =
       	new HashSet<>(Arrays.asList("Gates", "Buffett", "Bezos", "Zuckerberg"));
System.out.println("accounts= " + accounts);

Давайте соберем их в сет и распечатаем. Интересно, мы увидим их в том же самом порядке, в котором мы их завели?

A. Порядок объявления сохраняется
B. Порядок неизвестен, но сохраняется между запусками
C. Порядок неизвестен и меняется при каждом перезапуске JVM
D. Порядок неизвестен и меняется при каждой распечатке

Голосование в аудитории показало, что большинство – за вариант B, и это правильный ответ. Все прекрасно знают, что внутри хешсета – хешмеп, а в хешмепе – ключи.



С этим надо что-то делать! Поэтому мы переходим на Early Access Release Java 9 (банки всегда так делают, они используют все самое свежее). И тут все становится интереснее, так как тут появился метод Set.of, благодаря чему вместо всего этого длинного можно написать коротко.

Set<String> accounts = Set.of("Gates", "Buffett", "Bezos", "Zuckerberg");
System.out.println("accounts= " + accounts);

Вопрос остается таким же: если собрать в сет и распечатать, мы увидим счета в том же самом порядке, в котором мы их завели?

A. Порядок объявления сохраняется
B. Порядок неизвестен, но сохраняется между запусками
C. Порядок неизвестен и меняется при каждом перезапуске JVM
D. Порядок неизвестен и меняется при каждой распечатке

Голосование в аудитории показало, что большинство – за вариант С, и это правильный ответ. У нас есть доказательство. Мы можем воспользоваться новой замечательной штукой, которая появилась в девятой Java и называется JShell. Мы засовываем этот код, получаем какой-то порядок, повторяем, получаем другой порядок, повторяем, получаем третий порядок. Как это работает?



Это сделано специально. Вот таким образом вычисляется элемент таблицы по хеш-коду в этом самом  Set.of:

private int probe(Object pe) {
 	int idx = Math.floorMod(pe.hashCode() ^ SALT, elements.length);
 	while (true) {
       	E ee = elements[idx];
       	if (ee == null) {
                return -idx - 1;
       	} else if (pe.equals(ee)) {
                return idx;
       	} else if (++idx == elements.length) {
                idx = 0;
      	}
 	}
}

Видите, что там есть хеш-код ^ SALT, а SALT – это статическое поле, которое при запуске JVM инициализируется случайным числом. Это сделано специально, потому что слишком много людей закладывались на порядок хеш-сета, когда он не был определен и когда в документации черным по белому было написано: «не закладывайтесь на него». Поэтому было сделано так, что при попытке заложиться, вы просто перезапустите JVM, и это больше не сработает. Вы просто не сможете на это заложиться. Хотя тут есть опасность: некоторые могут заложиться, что эта штука работает случайно.

Java-паззлер №6: Jigsaw

Есть несколько утверждений про Jigsaw. Попробуйте угадать, какое из них правильное:

A. Если сделать приложение jigsaw модулем, зависимости в classpath будут подгружаться корректно
B. Если одна из зависимостей – jigsaw модуль, то обязательно прописать файл module-info
C. Если вы прописали файл module-info, то все зависимости придется прописать дважды, в classpath и в module-info
D. Никакое не верно

Правильный ответ – C. Конечно же, вам придется все прописывать дважды. Хорошие новости в том, что Gradle и Maven будут генерировать оба этих компонента для вас: и правильный classpath, и правильный module-info, поэтому вам не придется делать это ручками. Но если вы не работаете с этими инструментами, вам придется делать это два раза, хотя есть нюанс. Вы можете использовать флажок module-path, и там есть свой паззлер, но про него в следующий раз.

Java-паззлер №7: Неудержимые 2

У нас есть коллекция Неудержимых, и мы их всех хотим уничтожить. Уничтожать будем так: возьмем итератор и вызовем у него метод forEachRemaining. И для каждого элемента будем делать такую вещь: если там есть следующая запись, то мы передвигаемся и уничтожаем (и это все внутри forEachRemaining).

static void killThemAll(Collection<Hero> expendables) {
   	Iterator<Hero> heroes = expendables.iterator();
   	heroes.forEachRemaining(e -> {
            	if (heroes.hasNext()) {
                 heroes.next();
                 heroes.remove();
        }
   	});
   	System.out.println(expendables);
}

Какие есть варианты?

A. Все умерли
B. Только четные умерли
C. Все выжили
D. Только нечетные умерли
E. Все ответы верны

Правильный ответ – E. Это undefined behavior. Сюда можно попробовать подать разные коллекции, и если попробовать это сделать, мы получим разные результаты.

Если мы сюда подадим ArrayList, то мы получим, что все умерли.

killThemAll(new ArrayList<String>(Arrays.asList("N","S","W","S","L","S","L","V")));
[]<
/source>
Если мы сюда подадим <code>LinkedList</code>, то мы получим, что четные умерли

<source lang="java">killThemAll(new LinkedList<String>(Arrays.asList("N","S","W","S","L","S","L","V")));
[S,S,S,V]

Если мы сюда подадим ArrayDeque, то все останутся живы, и никаких исключений.

killThemAll(new ArrayDeque<String>(Arrays.asList("N","S","W","S","L","S","L","V")));
[N,S,W,S,L,S,L,V]

А если мы сюда подадим TreeSet, то, наоборот, умрут нечетные.

killThemAll(new TreeSet<String>(Arrays.asList("N","S","W","S","L","S","L","V")));
[N,W,L,L]

Поэтому никогда! Никогда так не делайте! На самом деле это получилось случайно — просто потому, что никто не думал, что кто-то так будет делать. Когда мы сообщили об этом в Oracle, они сделали что? Правильно, «пофиксили эту проблему», написав об этом в документации:

Java-паззлер №8: Незаметная разница

Хотим создать оригинальный, настоящий Adidas в виде предиката, который будет проверять, что это действительно Adidas. Мы создаем функциональный интерфейс, параметризуем его каким-то типом T и, соответственно, реализуем его в виде Лямбды или в виде methodRef:

@FunctionalInterface
public interface OriginalPredicate<T> {
    	boolean test(T t);
}
OriginalPredicate<Object> lambda = (Object obj) -> "adidas".equals(obj);
OriginalPredicate<Object> methodRef = "adidas"::equals;

Вопрос: скомпилируется это все или нет?

A. Оба скомпилируются
B. Ламбда скомпилируется, ссылка на метод – нет
C. Ссылка на метод скомпилируется, лямбда – нет
D. Не функциональный интерфейс!

Правильный ответ – A, тут фактически вообще нет паззлера. Но давайте сделаем функциональный интерфейс made in china.

@FunctionalInterface
public interface CopyCatPredicate {
   	<T> boolean test(T t);
}
CopyCatPredicate lambda = (Object obj) -> "adadas".equals(obj);
CopyCatPredicate methodRef = "adadas"::equals;

В чем отличие от предыдущего кода? Кроме adadas, мы перенесли generic из самого интерфейса в метод, и теперь у нас не класс generic, а метод generic. Можем ли мы создать функциональный интерфейс generic-методом?

A. Оба скомпилируются
B. Ламбда скомпилируется, ссылка на метод –нет
C. Ссылка на метод скомпилируется, лямбда –нет
D. Не функциональный интерфейс!

Правильный ответ – С. Вас предупреждали – метод лучше. Лямбда не может реализовывать generic метод. В Лямбде мы передаем параметр, мы должны указать ему тип. Даже если мы не укажем, он должен какой-то вывестись, но чтобы он вывелся, у нас должна быть generic-переменная. То есть там нужно сделать generic-лямбду, где-то в угловых скобочках написать T или не T (мы можем другую букву использовать). Но такого синтаксиса нет, не придумали и тогда решили, что, мол, давайте, ладно, но для Лямбды это работать не будет.  

@FunctionalInterface
public interface CopyCatPredicate {
   	<T> boolean test(T t);
}
CopyCatPredicate lambda = (Object obj) -> "adadas".equals(obj);

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

Java-паззлер №9: на какую конференцию сходить?

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

List<String> list = Stream.of("Joker", "DotNext", "HolyJS", "HolyJS",
"DotNext", "Joker").sequential()
             	.filter(new TreeSet<>()::add).collect(Collectors.toList());
System.out.println(list);

Что вы получите?

A. Отсортированные и отфильтрованные [DotNext, HolyJS, Joker]
B. Ровно то же, что было в начале [Joker, DotNext, HolyJS, HolyJS, DotNext, Joker]
C. В начальном порядке, но отфильтрованные [Joker, DotNext, HolyJS]
D. Отсортированные, но не отфильтрованные [DotNext, DotNext, HolyJS, HolyJS, Joker, Joker]

Правильный ответ – С. Фильтрация сработает потому что это метод reference, и объект TreeSet там будет один. Новички думают, что метод reference и Лямбда – это почти одно и то же, но это не совсем одно и то же. Если бы мы написали Лямбду, новый TreeSet создавался бы каждый раз, а так как это метод reference, он создается один раз перед тем, как мы эту всю фильтрацию делаем, и метод reference к нему привязывается. А ничего не отсортируется потому, что мы не используем то, что в TreeSet как результат, мы всего лишь используем метод add как фильтр, который отвечает нам true или false (нужно выкидывать дубликаты или нет). По сути дела, можно было написать просто distinct, и было бы то же самое. Результат этого трисета потом соберется GarbageCollector'ом, и никто не знает, что там будет.

Выводы

Java становится все лучше, и способов выстрелить себе в ногу становится намного больше. Поэтому вот парочка советов:

• Пишите читаемый код.
  
• Комментируйте все трюки, если не можете удержаться.
  
• Иногда даже в Java бывают баги, которые ставят вас в тупик.
  
• Статические анализаторы кода рулят! Используйте IntelliJ IDEA.
  
• Поскольку все баги чинятся добавлением строчек в документацию, документацию надо знать.
  
• Не болейте стримозом. Кстати, в самой новой IDEA вы можете превратить стрим в цикл, если он вам надоел.
  

Если вы наткнулись на паззлер, присылайте его на puzzlers@jfrog.com, с удовольствием проведем третий сезон на одной из следующих конференций. В обмен на ценный экземпляр мы вышлем вам фирменную футболочку.

---

Если вы любите смаковать все детали разработки на Java так же, как и мы, наверняка вам будут интересны вот эти доклады на нашей апрельской конференции JPoint 2018:

• Linux container performance tools for JVM applications (Sasha Goldshtein, Sela Group)
  
• Анализ программ: как понять, что ты хороший программист (Алексей Кудрявцев, JetBrains)
  
• Типовые проблемы разработки ПО в больших проектах (Рустам Мехмандаров, Computas AS)