ACTUALIZACIÓN: Esta respuesta es en respuesta a la pregunta original, ¿Java SE 8 tiene pares o tuplas? (E implícitamente, si no, ¿por qué no?) El OP ha actualizado la pregunta con un ejemplo más completo, pero parece que se puede resolver sin usar ningún tipo de estructura de pares. [Nota de OP: aquí está la otra respuesta correcta .]
La respuesta corta es no. Debe rodar el suyo o traer una de las varias bibliotecas que lo implementan.
Se Pair
propuso y rechazó tener una clase en Java SE al menos una vez. Vea este hilo de discusión en una de las listas de correo de OpenJDK. Las compensaciones no son obvias. Por un lado, hay muchas implementaciones de pares en otras bibliotecas y en el código de la aplicación. Eso demuestra una necesidad, y agregar tal clase a Java SE aumentará la reutilización y el uso compartido. Por otro lado, tener una clase Pair aumenta la tentación de crear estructuras de datos complicadas a partir de pares y colecciones sin crear los tipos y abstracciones necesarios. (Esa es una paráfrasis del mensaje de Kevin Bourillion de ese hilo).
Recomiendo a todos que lean todo el hilo de correo electrónico. Es notablemente perspicaz y no tiene daño. Es bastante convincente. Cuando comenzó, pensé: "Sí, debería haber una clase Pair en Java SE", pero cuando el hilo llegó a su fin, había cambiado de opinión.
Sin embargo, tenga en cuenta que JavaFX tiene la clase javafx.util.Pair . Las API de JavaFX evolucionaron por separado de las API de Java SE.
Como se puede ver en la pregunta vinculada ¿ Cuál es el equivalente del par C ++ en Java? Hay un espacio de diseño bastante grande que rodea lo que aparentemente es una API tan simple. ¿Deberían los objetos ser inmutables? ¿Deberían ser serializables? ¿Deberían ser comparables? ¿La clase debería ser final o no? ¿Deberían ordenarse los dos elementos? ¿Debería ser una interfaz o una clase? ¿Por qué parar en parejas? ¿Por qué no triples, cuádruples o tuplas N?
Y, por supuesto, existe el inevitable cambio de nombres para los elementos:
- (a, b)
- (primer segundo)
- (izquierda derecha)
- (coche, cdr)
- (foo, bar)
- etc.
Un gran problema que apenas se ha mencionado es la relación de los pares con los primitivos. Si tiene un (int x, int y)
dato que representa un punto en el espacio 2D, representarlo ya que Pair<Integer, Integer>
consume tres objetos en lugar de dos palabras de 32 bits. Además, estos objetos deben residir en el montón e incurrirán en gastos generales de GC.
Parecería claro que, al igual que Streams, sería esencial que hubiera especializaciones primitivas para pares. ¿Queremos ver:
Pair
ObjIntPair
ObjLongPair
ObjDoublePair
IntObjPair
IntIntPair
IntLongPair
IntDoublePair
LongObjPair
LongIntPair
LongLongPair
LongDoublePair
DoubleObjPair
DoubleIntPair
DoubleLongPair
DoubleDoublePair
Incluso un IntIntPair
todavía requeriría un objeto en el montón.
Estos, por supuesto, recuerdan la proliferación de interfaces funcionales en el java.util.function
paquete en Java SE 8. Si no desea una API hinchada, ¿cuáles dejaría de lado? También podría argumentar que esto no es suficiente, y que las especializaciones para, por ejemplo, también Boolean
deberían agregarse.
Mi sensación es que si Java hubiera agregado una clase Pair hace mucho tiempo, habría sido simple, o incluso simplista, y no habría satisfecho muchos de los casos de uso que estamos imaginando ahora. Tenga en cuenta que si se hubiera agregado Par en el marco de tiempo JDK 1.0, ¡probablemente habría sido mutable! (Mire java.util.Date.) ¿La gente habría estado contenta con eso? Supongo que si hubiera una clase Pair en Java, sería un poco no muy útil y todos seguirían implementando los suyos para satisfacer sus necesidades, habría varias implementaciones de Pair y Tuple en bibliotecas externas, y la gente todavía estaría discutiendo / discutiendo sobre cómo arreglar la clase Pair de Java. En otras palabras, más o menos en el mismo lugar en el que estamos hoy.
Mientras tanto, se está trabajando para abordar el problema fundamental, que es un mejor soporte en la JVM (y eventualmente en el lenguaje Java) para los tipos de valor . Ver este documento Estado de los valores . Este es un trabajo preliminar y especulativo, y cubre solo temas desde la perspectiva de JVM, pero ya tiene una buena cantidad de pensamiento detrás de él. Por supuesto, no hay garantías de que esto entrará en Java 9, o nunca entrará en ningún lado, pero sí muestra la dirección actual de pensar sobre este tema.
AbstractMap.SimpleImmutableEntry<K,V>
desde hace años ... Pero de todos modos, en lugar de la cartografíai
a(i, value[i])
simplemente para filtrar porvalue[i]
ida y vuelta a la cartografíai
: ¿por qué no filtrovalue[i]
en el primer lugar, sin la asignación?