Есть ли в Java SE 8 пары или кортежи?

ОБНОВЛЕНИЕ: Этот ответ является ответом на исходный вопрос: Есть ли в Java SE 8 пары или кортежи? (И если нет, то почему бы и нет неявно?) OP обновлен вопрос с более полным примером, но похоже, что он может быть решен без использования какой-либо парной структуры. [Примечание от OP: вот другой правильный ответ.]

Краткий ответ: нет. Вы должны либо использовать свой собственный, либо использовать одну из нескольких библиотек, которые его реализуют.

Наличие класса Pair в Java SE было предложено и отвергнуто по крайней мере один раз. См. эту ветку обсуждения на одном из списки рассылки OpenJDK. Компромиссы не очевидны. С одной стороны, существует множество реализаций Pair в других библиотеках и в коде приложения. Это демонстрирует необходимость, и добавление такого класса в Java SE увеличит повторное использование и совместное использование. С другой стороны, наличие класса Pair добавляет соблазна создавать сложные структуры данных из пар и коллекций без создания необходимых типов и абстракций. (Это пересказ сообщения Кевина Буриллиона из той ветки.)

Я рекомендую всем прочитать всю эту цепочку писем. Это удивительно проницательно и без оглядки. Вполне убедительно. Когда это началось, я подумал: «Да, в Java SE должен быть класс Pair», но к тому времени, когда поток достиг своего конца, я передумал.

Однако обратите внимание, что JavaFX имеет javafx.util.Pair класс. API-интерфейсы JavaFX развивались отдельно от API-интерфейсов Java SE.

Как видно из связанного вопроса Что такое эквивалент пары C ++ в Java? очевидно, что такой простой API окружает довольно большое пространство дизайна. Должны ли объекты быть неизменными? Должны ли они быть сериализуемыми? Должны ли они быть сопоставимы? Занятие должно быть окончательным или нет? Следует ли заказывать два элемента? Это должен быть интерфейс или класс? Зачем останавливаться на парах? Почему не тройки, квадраты или N-кортежи?

И, конечно же, существует неизбежное именование элементов велосипедной навесы:

• (a, b)
• (первая секунда)
• (лево право)
• (автомобиль, cdr)
• (фу, бар)
• и Т. Д.

Одна большая проблема, о которой почти не упоминалось, - это отношение пар к примитивам. Если у вас есть (int x, int y) датум, представляющий точку в двухмерном пространстве, то представление Pair<Integer, Integer> потребляет три объекта вместо двух 32-битных слов. Кроме того, эти объекты должны находиться в куче и будут вызывать накладные расходы сборщика мусора.

Казалось бы, очевидно, что, как и в случае с потоками, для пар необходимо наличие примитивных специализаций. Хотим ли мы увидеть:

Pair
ObjIntPair
ObjLongPair
ObjDoublePair
IntObjPair
IntIntPair
IntLongPair
IntDoublePair
LongObjPair
LongIntPair
LongLongPair
LongDoublePair
DoubleObjPair
DoubleIntPair
DoubleLongPair
DoubleDoublePair

Даже IntIntPair все равно потребуется один объект в куче.

Это, конечно, напоминает распространение функциональных интерфейсов в пакете java.util.function в Java SE 8. Если вам не нужен раздутый API, какие из них вы бы не использовали? Вы также можете возразить, что этого недостаточно и что следует добавить специализации, скажем, для Boolean.

Мне кажется, что если бы Java давным-давно добавила класс Pair, это было бы просто или даже упрощенно и не удовлетворило бы многие варианты использования, которые мы сейчас представляем. Учтите, что если бы Pair была добавлена ​​во временные рамки JDK 1.0, она, вероятно, была бы изменяемой! (Посмотрите на java.util.Date.) Были бы люди довольны этим? Я предполагаю, что если бы в Java был класс Pair, он был бы своего рода-сортировкой-не-действительно-полезным, и каждый по-прежнему будет использовать свой собственный, чтобы удовлетворить свои потребности, были бы различные реализации Pair и Tuple во внешних библиотеках, и люди все еще спорили / обсуждали, как исправить класс Java Pair. Другими словами, примерно в том же месте, где мы находимся сегодня.

Между тем ведется некоторая работа по решению фундаментальной проблемы, а именно лучшей поддержки в JVM (и, в конечном итоге, в языке Java) для типов значений. См. Этот документ Состояние значений. Это предварительная, спекулятивная работа, и она охватывает только проблемы с точки зрения JVM, но за ней уже стоит изрядное количество размышлений. Конечно, нет никаких гарантий, что это войдет в Java 9 или когда-либо попадет куда-нибудь, но это действительно показывает текущее направление мышления по этой теме.

Вы можете взглянуть на эти встроенные классы:

• AbstractMap.SimpleEntry
• AbstractMap.SimpleImmutableEntry

К сожалению, в Java 8 не было пар или кортежей. Вы всегда можете использовать org .apache.commons.lang3.tuple, конечно (который лично я использую в сочетании с Java 8), или вы можете создать свои собственные оболочки. Или используйте Карты. Или тому подобное, как описано в принятом ответе на вопрос, на который вы указали.

ОБНОВЛЕНИЕ: JDK 14 представляет записи в качестве функции предварительного просмотра. Это не кортежи, но их можно использовать для решения многих из тех же проблем. В вашем конкретном примере сверху это может выглядеть примерно так:

public class Jdk14Example {
    record CountForIndex(int index, long count) {}

    public static void main(String[] args) {
        boolean [][] directed_acyclic_graph = new boolean[][]{
                {false,  true, false,  true, false,  true},
                {false, false, false,  true, false,  true},
                {false, false, false,  true, false,  true},
                {false, false, false, false, false,  true},
                {false, false, false, false, false,  true},
                {false, false, false, false, false, false}
        };

        System.out.println(
                IntStream.range(0, directed_acyclic_graph.length)
                        .parallel()
                        .mapToObj(i -> {
                            long count = IntStream.range(0, directed_acyclic_graph[i].length)
                                            .filter(j -> directed_acyclic_graph[j][i])
                                            .count();
                            return new CountForIndex(i, count);
                        }
                        )
                        .filter(n -> n.count == 0)
                        .collect(() -> new ArrayList<CountForIndex>(), (c, e) -> c.add(e), (c1, c2) -> c1.addAll(c2))
        );
    }
}

При компиляции и запуске с JDK 14 (на момент написания это сборка раннего доступа) с использованием --enable-preview, вы получите следующий результат:

[CountForIndex[index=0, count=0], CountForIndex[index=2, count=0], CountForIndex[index=4, count=0]]

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

Код, который это делает, находится здесь:

    System.out.println(
        IntStream.range(0, acyclic_graph.length)
            .filter(i -> IntStream.range(0, acyclic_graph.length)
                                  .noneMatch(j -> acyclic_graph[j][i]))
            .boxed()
            .collect(toList()));

Это приводит к выводу [0, 2, 4], который, я думаю, является правильным результатом, запрошенным OP.

Также обратите внимание на операцию boxed(), которая помещает значения int в объекты Integer. Это позволяет использовать уже существующий toList() коллектор вместо того, чтобы записывать функции коллекторов, которые сами выполняют упаковку.

Начиная с Java 9, вы можете создавать экземпляры Map.Entry проще, чем раньше:

Entry<Integer, String> pair = Map.entry(1, "a");

Map.entry возвращает неизменяемое Entry и запрещает нули.

Vavr (ранее называвшийся Javaslang) (http://www.vavr.io) предоставляет кортежи (до 8). Вот javadoc: https://static.javadoc.io/io.vavr/vavr/0.9.0/io/vavr/Tuple.html.

Это простой пример:

Tuple2<Integer, String> entry = Tuple.of(1, "A");

Integer key = entry._1;
String value = entry._2;

Почему до сих пор в JDK не было простого вида кортежей, для меня загадка. Написание классов-оберток кажется повседневным делом.

да.

Map.Entry можно использовать как Pair.

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

А пока от этого мало пользы.

РЕДАКТИРОВАТЬ 2021-05-10: Java 16 принесла записи, что является очень хорошим решением этой и других проблем. Очень веская причина для таргетинга на Java 17 LTS в ближайшее время

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

     int[] value =  ...


IntStream.range(0, value.length)
            .filter(i -> value[i] > 30)  //or whatever filter you want
            .forEach(i -> System.out.println(i));

Коллекции Eclipse имеют Pair и все комбинации пар примитив / объект (для всех восьми примитивов).

_ 2_ может создавать экземпляры Pair и _ 4_ factory можно использовать для создания всех комбинаций пар примитив / объект.

Мы добавили их до того, как была выпущена Java 8. Они были полезны для реализации итераторов ключ / значение для наших примитивных карт, которые мы также поддерживаем во всех комбинациях примитив / объект.

Если вы хотите добавить дополнительные накладные расходы библиотеки, вы можете использовать принятое Стюартом решение и собрать результаты в примитив IntList, чтобы избежать боксов. Мы добавили новые методы в Eclipse Collections 9.0, чтобы разрешить Int/Long/Double коллекции, которые будут созданы из Int/Long/Double Streams.

IntList list = IntLists.mutable.withAll(intStream);

Примечание: я являюсь приверженцем коллекций Eclipse.