text: Java Needs to Get a Pair (and a Triple...)
  Options for returning multiple parameters in Java are limited. Discover a good way to get around this limitation.
  When Java was first created, its simplicity was a reversal of the increasing complexity (and, let's be fair, flexibility) of C++. Pointers and memory management were simplified, including elimination of parameter indirection, const, function pointers and other powerful but often confusing features. In C++ you can pass parameters by value (like in Java) or by reference, allowing the reference to be reassigned in the method and providing you with out parameters, or a way of returning more values from a method than the one return value allowed by the syntax. The signatures that can end up with char** and & dereferences throughout the code might be unsightly to some, but they are quite useful.
  In Java, what you are left with is method parameters being passed by value and cannot be outparams, while methods can only return one argument. This certainly works, look at any significant codebase and you will see plenty of examples, but it's not particularly efficient in developer time.
  Let's take a return class with two arguments - say a name and a date of birth:
  Obviously this is a manufactured example, and the chances are you probably have a Person class already defined that you could maybe return instead. I would also bet that you have examples of your own where you want to return two different objects from a method but don't have a class already defined for them, or maybe you end up returning a class with far more information than necessary in order to just get a couple of items out of it. Depending on the circumstance that might be even worse. For example, what if the person calling your method starts to use or even modify values in that returned object when you had no intention of letting that happen?
  The above is more code than is needed anyway. This is meant to be a lightweight way of returning some values from a method, so let's make some simple changes:
  The result is shorter, and more fit for the task. Values are being returned, so there is no need for setters, let's just set up the values when the return object is created. They don't need to change, and since they are in a constructor, they can be made final. Now that they are final, there is no risk to making the class attributes themselves public, since they can't be side affected, so now you can get rid of the getters as well as the setters. The result is shorter and easier to use:
  I like this approach to lightweight return objects. It is typesafe, so there is no need to cast objects out of arrays after return. Even better, the final modifier on the attributes means that these return objects cannot be abused - they are simply for transfer of data.
  from side affecting the original dob value which is a huge risk otherwise. Immutable values rock, and if you can't use those, then be sure to take copies and return those copies in your results instead.
  You aren't finished yet with the Pair class though. Some of the things you need to consider if this thing is going to be truly universal:
  You don't want someone extending the Pair class and changing what it does - that might break the original intent of the class.
  So, let's see how that changes the pair implementation up:
  The equals() and hashCode() methods mean that this class can be used for more purposes than just returning values. They can used, for example, as the key to a map. A recommendation here, for any kind of return object using this pattern, is to let your IDE create the equals and hashCode methods for you - these are simple implementations but even here there are some things to remember about the contract with hashCode and equals, for example null checks and different types (see the excellent description in Josh Bloch's Effective Java 2nd ed. for the definitive writeup on the subject). IDEs tend to have boilerplate insertions with the best practices already defined, so I just had NetBeans create these for me. Perhaps they could be streamlined a little, but these implementations are safe. I did remove the generic signature from the NetBeans equals() implementation though, as it is not necessary and could create confusion.
  The toString() override just prints a pretty form of the pair, like "Pair[Fred Jones,Sun Mar 22 12:55:44 PDT 2009]". This is particularly useful for, say, debugging popups.
  Yes, and no! This class is in use at Navigenics where it performs well. Doubtless there are other similar implementations all over other Java applications out there, which probably offer the same feature set and are as useful. Is it complete then? From a "we can use it as it is for most foreseeable needs", then yes it is complete. From a "will it be the only pair we will ever need" then possibly not.
  For example, Pairs represented by this class cannot be compared. I thought about adding a compareTo() method and making it Comparable but here you start to hit the complexity that even simple general class design brings up. In very general usage, what is the correct behavior for it? It's easy to say that you compare the first value, and if they are equal, compare the second value. This is likely the most consistent behavior, but is it right for every usage of Pair? You would also need to check if the classes being compared are themselves comparable, and if not use what? The object reference comparison?
  I sidestepped the issue. I know enough from writing that less is usually more, or as my thesis tutor used to say: "Omit Unnecessary Words". If someone wants their Pair usage to be comparable, they can supply a comparator to do it. After all, Lists are not Comparable in the Java SE libraries either.
  Pair also isn't Cloneable, and this would be easy enough to add. Perhaps it should be, but it's also really easy to clone a Pair (just create a new Pair of the first and second from another Pair). It seems unnecessary.
  Now I don't know about you, but I have some style issues with references like triple.second.second from a readability perspective compared with a simple triple.third. Not to mention the definition Triple<String, Integer, Date> is a lot cleaner than Pair<String, Pair<Integer, Date>>.
  The implementation of Triple is simple enough - take the Pair class and add a third attribute with a generic class C. Adjust the equals, hashCode, of and toString methods plus the constructor accordingly, and you are done.
  Creating a Pair class for Java is hardly in the realm of rocket science, but even here, in the implementation of a simple generalized library class, one which requires no language changes to Java and one with a very small feature list, some questions still exist. Generality are troublesome. Imagine then the problems facing some of the questions about the "small" language changes to be added to Java 7 with Project Coin. I do not envy the work ahead for the language designers and would-be language designers in implementing these changes without (hopefully) disrupting anything important in the general uses of the language.
  Finally, I would like to say thanks in particular to Tomas Zezula, a NetBeans engineer whose Pair implementation in the open source NetBeans codebase provided valuable considerations in the construction of this article. Interestingly Pair appears (as far as I can tell) in 11 different locations in the NetBeans codebase alone. Yes, I would say one is needed in the Java SE libraries...