Как проект янтаря революционизирует Java

 // now; compile error: "ambiguous method call" method(s -> false) private void method(Predicate<String> p) { /* ... */ } private void method(Function<String, String> f) { /* ... */ } 

Странно, что компилятор считает, что это неоднозначно, потому что для нас это не так. Когда лямбда-остатки реализованы, компилятор соглашается.

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

 // maybe in the future // ignore the parameter marked as `_` BiFunction<Integer, String, String> f3 = (i, _) -> String.valueOf(i); // if there were a TriFunction: BiFunction<Integer, String, String, String> f3 = (i, _, _) -> String.valueOf(i); 

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

 private Map<String, Integer> wordLengthCache; // now public int computeLength(String word) { // can't reuse `word` in lambda, so... maybe `w`? wordLengthCache.computeIfAbsent(word, w -> w.length()); } // maybe in the future public int computeLength(String word) { // can't reuse `word` in lambda, so... maybe `w`? wordLengthCache.computeIfAbsent(word, word -> word.length()); } 

Для получения дополнительной информации взгляните на JEP 302 .

Классы данных

Мы все создали множество простых классов-держателей данных, для которых требовались десятки строк кода для полей, конструктора, методов доступа, equals , hashCode , toString . В то время как IDE успешно генерируют все это, что делает его ввод ненужным даже сегодня, это все еще код, который необходимо понять (конструктор выполняет какую-либо проверку?) И поддерживать его (лучше не забывать добавлять это новое поле в equals).

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

 // maybe in the future public class User(String firstName, String lastName, DateTime birthday) { } 

Мы можем получить все остальное, что я упомянул выше, бесплатно, и нам нужно только реализовать то, что является нестандартным (возможно, у пользователей есть идентификатор, который сам определяет равенство, поэтому мы бы хотели, чтобы была реализована equals реализация). Избавление от всего этого кода было бы большим стимулом для удобства обслуживания!

(Для этого предложения пока нет JEP, но Эмбер примет его, как только оно будет.)

Сопоставление с образцом

Текущий оператор switch Java довольно слабый. Вы можете использовать его для примитивов, перечислений и строк, но это все. Если вы хотите сделать что-то более сложное, вы либо прибегаете к цепочкам if — else — if либо, если вы не можете выбросить из головы книгу «Банды четырех», — шаблон посетителей .

Проект Amber исследует то, что обычно называют сопоставлением с образцом. Он работает со всеми типами, может иметь более сложные условия, чем проверки на равенство, и является выражением, означающим, что ему может быть присвоено значение. Вот пример, который Брайан показал в Devoxx Belgium несколько месяцев назад:

 // maybe in the future String formatted = switch (constant) { case Integer i -> String.format("int %d", i); case Byte b: //... case Long l: // ... // ... default: formatted = "unknown" } 

(Для этого предложения пока нет JEP, но Эмбер примет его, как только оно будет.)

Проект Янтарь

Теперь, когда мы знаем, какие функции в настоящее время изучаются в рамках проекта Amber, пришло время более подробно рассмотреть сам проект. В приветственном письме описывается «инкубационная площадка для отдельных JEP, ориентированных на производительность, на языке Java». Скажем в общих чертах, его область действия определяется как любой JEP, который группа экспертов находит интересным, и согласуется с общим утверждением миссии: