更新： 此答案是对原始问题的回答， Java SE 8是否具有对或元组？
（如果不是，则隐式地，为什么不这样做？）OP用一个更完整的示例更新了该问题，但似乎无需使用任何一种Pair结构即可解决该问题。OP的注：这是[另一个正确答案。
似乎完整的示例可以在不使用任何种类的Pair结构的情况下解决。关键是过滤列索引，用谓词检查整个列，而不是将列索引映射到该列中的
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()收集器，而不必写出自己进行装箱的收集器功能。
最简洁的答案是不。您要么自己动手，要么引入实现它的几个库之一。
Pair建议在Java
SE中创建一个类，并至少拒绝一次。请参阅OpenJDK邮件列表之一上的讨论线程。权衡并不明显。一方面，其他库和应用程序代码中有许多Pair实现。这就表明有必要，将这样的类添加到Java
SE中将增加重用和共享。另一方面，拥有Pair类增加了在Pairs和collections中创建复杂的数据结构而不创建必要的类型和抽象的诱惑。（这是凯文·布洛里恩（Kevin
Bourillion）从该帖子发出的信息的解释。
我建议大家阅读整个电子邮件主题。它非常有见地，没有发炎。这很有说服力。刚开始的时候我以为“是的，Java
SE中应该有一个Pair类”，但是到线程结束时，我改变了主意。
但是请注意，JavaFX具有javafx.util.Pair类。JavaFX的API与Java
SE API分开发展。
从链接的问题中可以看出，Java中的C
++对相当于什么？很显然，围绕如此简单的API的设计空间很大。对象应该是不可变的吗？它们应该可序列化吗？它们应该具有可比性吗？上课应该是最后的吗？这两个元素应该排序吗？应该是接口还是类？为什么要结伴而行？为什么不使用三元组，四元组或N元组？
当然，元素的命名不可避免：
- （a，b）
- （第一秒）
- （左右）
- （汽车，cdr）
- （foo，bar）
- 等等
几乎没有提到的一个大问题是成对与基元的关系。如果您有一个
(int x, inty)表示2D空间中一个点的基准，则将该基准表示为
Pair<Integer, Integer>消耗 三个对象
而不是两个32位字。此外，这些对象必须驻留在堆上，并且会产生GC开销。
显然，像Streams一样，对于Pairs而言，必须具有原始的专业化知识。我们是否想看看：
PairObjIntPairObjLongPairObjDoublePairIntObjPairIntIntPairIntLongPairIntDoublePairLongObjPairLongIntPairLongLongPairLongDoublePairDoubleObjPairDoubleIntPairDoubleLongPairDoubleDoublePair
即使
IntIntPair仍然需要堆上有一个对象。
当然，这些使人想起
java.util.functionJava SE
8软件包中功能接口的泛滥。如果您不希望使用膨胀的API，那么您会忽略哪些？您还可以说这还不够，因此还
Boolean应该添加专门的领域。
我的感觉是，如果Java很久以前添加了Pair类，那将是简单的，甚至是简单的，并且它不会满足我们现在设想的许多用例。考虑一下，如果在JDK
1.0的时间范围内添加了Pair，那么它可能是可变的！（查看java.util.Date。）人们对此会感到满意吗？我的猜测是，如果Java中有一个Pair类，那将有点用处而不是真正有用，并且每个人仍然会自己滚动以满足他们的需求，外部库中将有各种Pair和Tuple实现，而且人们仍然会争论/讨论如何修复Java的Pair类。换句话说，有点像我们今天所处的位置。
同时，正在进行一些工作来解决基本问题，即在JVM（最终是Java语言）中为 值类型提供
更好的支持。请参阅此价值状态文档。这是初步的，推测性的工作，仅涵盖了JVM角度的问题，但背后已经有很多思考。当然，我们不能保证它会进入Java
9，也不会进入任何地方，但确实显示了有关此主题的最新思路。
