Today was one of those days when I wished Java would support multiple return values. I had to develop a rather CPU-intensive algorithm which would compute a solution for a knotty constraint problem. Having a solution alone is sometimes not enough and you also need to add some parameters which measure the quality of the computed outcome. Most of these accompanying parameters can or have to be computed within the algorithm itself, but Java allows you to return only one value either an object or a primitive type. People working with Lisp, MATLAB or Perl, just to mention a few, don't have a problem like this at all. Functions supporting multiple return values is already implemented at the language level and frameworks make heavy use of this. But as a Java programmer you are pretty much stuck here and need to consider some other means to come out of this situation. In the following I would like to give some hints on that topic. Hopefully they are of help for anyone having the same problem every now and then.

That java link was nice...thanks. Once you start using tuples in other languages like Python you want to use them in everything. I looked at the code hoping it wouldn't be a big mess and it seems pretty clean. Its not a hard concept.

I didn't see a mention of a license in the download though. The site does say

You can compile the source into a jar, or make it part of your project directly.

... so it might be public domain?

EDIT: Just saw it on the bottom.... Creative Commons Attribution 3.0 United States License.

With C++ you'd just pass multiple values by reference, rather than muck about trying to "return" multiple values.

Then there is no "contract" in the function prototype. It is nice to know by looking at the arguments what can be changed and what can't be changed. You wind up looking at the code to see what is really going on, or actually reading the documentation which nobody wants to do.

Pointers are an ugly hack. The output variable is an input to the function?

Er, not really. const is a standard feature in C++ for declaring, well, constants. Same as it is in C, and it's been that way forever. It's hardly a hack: certainly no more than inventing silly ways to return multiple values from a function.

Java doesn't have data structs so it would have to be a class but the same concept works.

In fact it makes sense... if you're returning multiple values, they have a relationship. Chances are that that relationship will be studied elsewhere in the code. For instance other methods will take as input both of those pieces of data. Or there will be methods that specifically massage that data. What better place to put them than in this return value class? So in the end such a class almost always pays off by making code easier to read and more organized.

My first thought in C++ would be to have a templated ReturnTriple struct along the lines of:

template
struct ReturnTriple
{
A first;
B second;
C third;
};

which is cheap, type-safe and reusable.

The first poster on here gave a nice link for javatuple which does something very similar. I just looked and it seems real nice. it has classes for Single, Pair, Triple etc. up to Decuple.
I'm not sure if your C++ example retains type safety but this javatuple package does.

EDIT: Or, as another poster pointed out, just pass parameters by reference. Is this not possible in Java?

Java has Objects and primitives (because back in the day people were bitching about performance). Primitives are pass by value, Objects are passed as a reference. This means that if you pass a Vector to a method, because it is an Object, if you add or remove from that Vector in the method the changes will be visible after the method is called. However, even though Integer is a class, there are no methods to change the value of one. So, a method that needs to return two integers could return a List<Integer> or an Integer[], but things get ugly when you need to return an Integer and a String.

As it is stated in the next thread, returning multiply results from function absolute most of the time means bad design.

Applied to the example you gave.
You should spend some time and understand what are these tables used for and for how long. If these hashtables are used often I see no reason why shouldn't you use a wrapper. This wrapper may have some of the fetch and common processing logic loaded into to break data and computation apart. If they are short lived - why do you need a separate getter for them anyway?

I don't see your problem, then again I don't know what you are trying to achieve in your program.
I never had the urge to use a multi-value return and I also came from a C++ environment, I never used it because good OO design never needed it.
Sorry to point this out but the fact that you nullify the class field 'h1' before returning the (reference) copy, tells me that you either do not fully understood how Java works or you need some serious OO design classes.

Sorry to point this out but the fact that you nullify the class field 'h1' before returning the (reference) copy, tells me that you either do not fully understood how Java works or you need some serious OO design classes.

People should also stop using returning implementation types rather than interfaces (in this case HashTable).

I don't see your problem, then again I don't know what you are trying to achieve in your program.
I never had the urge to use a multi-value return and I also came from a C++ environment, I never used it because good OO design never needed it.
Sorry to point this out but the fact that you nullify the class field 'h1' before returning the (reference) copy, tells me that you either do not fully understood how Java works or you need some serious OO design classes.

It is client server. The client needs the HashTables two different ways. Nullifying it on the server and returning it to the client makes it a candidate for garbage collection on the server where I didn't want it hanging around.

All I'm saying is that there are places where multiple return values would be nice. It is basically returning a tuple but without creating meaningless wrapper classes.

It is client server. The client needs the HashTables two different ways. Nullifying it on the server and returning it to the client makes it a candidate for garbage collection on the server where I didn't want it hanging around.
All I'm saying is that there are places where multiple return values would be nice. It is basically returning a tuple but without creating meaningless wrapper classes.

This this does not explain this piece of code. When there are no references to a object then the garbage collector will reap it. Nullifying an object only helps if you have the only reference to an object but you just passed a copy as return value, hence: there is still a reference.
As for the fact that it is a client-server application, when the protocol you use is done sending the stuff over, the protocol will release it's reference and it will most likely kick in the garbage collector. Still: an experienced Java programmer would never write code like this. And: an experienced Java programmer would never NEED multiple return values.

If you don't see a reason why I should use a wrapper object, then why don't you see a reason for multiple return values?
It is doing the exact same thing logically.

No and no. First - no sequence of variables covered in obscure "tuple". This defy the very basic ideas of OO programming like encapsulation. Second - I've suggested not a wrapper object but rather an entity on it's own aware of how to fetch the data, how is it encoded, how it needs to be pre-processed etc. This will allow you to decouple supplier from consumer.

It isn't often that I need to return multiple things. Hardly ever. I just mentioned one case where it made sense.

If I wanted to be "object oriented" using getters I could call one method compute() like so...

And the case may point out to a deeper design problem.
I suggest you look once again at each and every case you think you must use more then one return value and try to avoid this at all cost.

I think it's pretty clear from reading this article that you have very little experience in solid object oriented design. No developer worth his salt would implement a generic "two return value" wrapper like that. If you have a set of related information that gets returned, the proper way to handle it is to design a class that represents that object, and contains methods to analyze its data.

The solution you suggest is an arbitrary pairing of potentially unrelated data in a too-generic fashion, from which no meaning can be derived - and is therefor a horrible design.

I may also point out that if you NEED multiple return values (which you don't, you want them, but noone ever needs them), and another languages supports them, then clealy Java was the wrong choice in the first place.

I think it's pretty clear from reading this article that you have very little experience in solid object oriented design. No developer worth his salt would implement a generic "two return value" wrapper like that. If you have a set of related information that gets returned, the proper way to handle it is to design a class that represents that object, and contains methods to analyze its data.

The solution you suggest is an arbitrary pairing of potentially unrelated data in a too-generic fashion, from which no meaning can be derived - and is therefor a horrible design.

Right. Classes like Point, PairOfShoes, Triangle, ... instead of TwoReturnValues and ThreeReturnValues. And if the values don't relate the method should get refactored.

I definitely second everybody who suggested that the author needs a better design rather than having the programming language to implement something non-sense.

If you need multiple return values, that means your method is coding too much logic into it and why don't you code everything in main and if that is the case, you don't need Java or even OO, just go back to any procedural language and even in those you only need main method.

A method (no matter it's in object or procedural) is a unit that serves a unique purpose. You code minimum logic into one method and this is why you unit test your method (some suggests you unit test on object, not method). A method is following a simple processing model:

Input->Process->Output

If you identify only one output and you will know what you need from input and process. In this case, if you need more than one return value, I guess you should start again to understand the fundamental of programming.

2. Return an object reference, and test for null. Example: ObjectRef populateObject(). A null return means it failed. This is one reason I rarely use int as a return, but instead use an Integer. Then I can just test for null.

3. The best approach to do what you want (have a function return both a value and some status flag) is to use exceptions. Example: ObjectRef populateObject() throws ObjectPopulationException. Then your external code would use a try/catch to call this function. This is the norm with languages that supports exception handling.

I usually try to avoid this, since Java does not codify your intention in the method signature. The obvious danger is that if it happens more than once in a library that you will confuse the library user. If it happens only a few times, you will suprise the user. It's a solution, but be careful!

Actually, I am happy C++ allows pass by value (where a value can also be a pointer), and pass by reference. If you really want to modify variables or instances provided through a parameter list, you can make this more explicit by using a pointer (without constness).

2. Return an object reference, and test for null. Example: ObjectRef populateObject(). A null return means it failed. This is one reason I rarely use int as a return, but instead use an Integer. Then I can just test for null.

That's usually not a good idea for math-intensive code due to all the boxing/unboxing that takes place. At other places this can be a good solution, if documented.

If the return type is a floating point type, and the parameters cause an invalid result, returning NaN is an option.

3. The best approach to do what you want (have a function return both a value and some status flag) is to use exceptions. Example: ObjectRef populateObject() throws ObjectPopulationException. Then your external code would use a try/catch to call this function. This is the norm with languages that supports exception handling.

Be careful there as well. Exceptions are for when... something exceptional happens. The danger is misusing exceptions as a mechanism to return values. Of course, Java does provide some good exceptions for common exceptional occasions. For those cases, prefer one of the exceptions that Java defines.

Having a solution alone is sometimes not enough and you also need to add some parameters which measure the quality of the computed outcome. Most of these accompanying parameters can or have to be computed within the algorithm itself, but Java allows you to return only one value either an object or a primitive type. [...] But as a Java programmer you are pretty much stuck here and need to consider some other means to come out of this situation.

Actually, you are mistaking a inherent property of Java and other static-typing languages as a disadvantage. If used properly, it is an advantage: the person implementing the caller code can exactly see by looking up the function or method declaration what to expect. This is a potential downside of dynamic languages, that can usually return anything, as long as it is (usually) a reference to something.

With the proposed solution, there's a risk of returning something that is potentially meaningless to the caller. Therefore, in such situations it's normally best to either: use more getters (where appropriate), or if the data in strongly coupled (which appears to be the case in the example mentioned in the article) return it as a class with its own getters.

Sure, there are situations where tuple-like classes can be useful. A good example is std::pair in C++, which is used for data stored within a map. The first element of the pair is used as the key, the second element as the value. Most if not all (since std::map provides ordering guarantees) implementations of std::map store these pairs in a binary tree that is ordered by the key. It's also convenient for iteration.

But for what my opinion is worth, this article makes a design error, it's the kind of approach you'll want to avoid in a static-typing OO language.

I am getting depressed from this discussion. All this "if you want to return multiple values, your design is wrong" nonsense. It's useful! Try it in Python, at least once.

The reason why Java (and C and it's predecessors) didn't support it is historical and comes from mathematics. In mathematics, functions that return multiple objects are useless, because you can just have multiple functions.

However, in programming, you often need to compute something and you get some other useful result as a side-effect of that computation. Classic example is the quotient/remainder example in the integer division. To split it into two functions, you would have to do the division twice, which would be silly. Sure, you can also wrap them into an object or struct or whatever, but compare this to Python, where you just "return them" and it's completely natural.

So please, stop saying that just because your language of choice doesn't support it, it's not useful. Because it is.

Classic example is the quotient/remainder example in the integer division. To split it into two functions, you would have to do the division twice, which would be silly. Sure, you can also wrap them into an object or struct or whatever, but compare this to Python, where you just "return them" and it's completely natural.

I don't see any problems in creating an object for that. Even if you think it will overhead, when you pass it as an arguments to another method, you'll find the object very usefull, because you only have manage one variable per result. Additionally I like the idea of not changing method signatures (and thus breaking backward compatibility), just because I need another argument.

Well, Python also creates an object (a tuple), so you can actually retrieve and manipulate the return values together. So this is a solved problem.

Anyway, my point is it's not always quite useful to define an object. In some cases yes, for example, if you have a point in 3D, then you probably want to have it as an object.

But in some cases, it is pointless to have an object "result of integer division". So why even bother?

Imagine a language where you can only have functions with one argument. Sounds silly? But it is exactly what you are defending. You could also say, well, you can always construct an object from the arguments, and it will be helpful in many cases. You could also say that it would be good because the function signature would never change.

In fact, I don't see any reason why it couldn't be completely symmetric. Thus, why cannot we have multiple return values, default return values, keyword return values and unlimited number of return values. The only reason I see is historic - we are used to notation that doesn't allow all of this stuff.

Imagine a language where you can only have functions with one argument. Sounds silly?

At first glance, yes. But let's think this some further: Normally you just put "something" and "something" into a method and getting a "something" and maybe another "something" back. Like this:

(c,d) = divide(a,b);

If you find this call in a sourcecode: How do you know, what's the divisor, remainder, etc.? You have to look at the documentation and interpret the call.
Now imagine this example in a one-parameter-,one-return-value-language:

Ok, it's much more to code, but it's much easier to understand, without looking at the documentation.
A good solution in the middle of this, would be named parameters/return values, so you can easily see what's going in and out.
If you just want multiple "somethings" as return values, define the return value as Object[].

So, you basically agree with me that the situation with input and output values is symmetric.

However, I don't agree that the second example you give is more readable. In a large program, every line and every technicality obscures the high-level structure. To show you the types of parameters of function you are looking at is a job for IDE or some source code browsing tool, and it should not be needed to write it up again and again endlessly in the source itself.

I'm in Java programming for 9 years now, but never really seen a problem with multiple return types.
Normally I would prefer the data object style to return multiple values, because the data returned from one method is often related. So the object groups the data and dealing with the related informations is much easier. Changing the information is much easier, too. Think about:
Position calculatePosition(), goTo(Position pos), runFrom(Position pos)...
instead of:
int[] calculationPosition(), goTo(int x, int y, int z), runFrom(int x, int y, int z)...

If the data one method returns is not related, you should double-check your code, because it smells (see "code smells").

Now tell me that ain't useful? Of course it's not something you need everyday (and it might really be bad design in many cases), but there are cases where you want to return two things that are not so closely connected to each other that they really belong into the same class.

I have used it in Python before and it's very useful. I wish Java had this.

Now tell me that ain't useful? Of course it's not something you need everyday (and it might really be bad design in many cases), but there are cases where you want to return two things that are not so closely connected to each other that they really belong into the same class.

Sure you can do the same thing. Return an immutable list of 'Object's. Because that's what Python actually does (it returns a tuple). That's different than allowing for multiple return types (viewed from a static language).

People don't do this, because it sacrifices type safety. Of course, you will have to cast it back to some class type to make its methods visible again. (And you can't apply some of the syntactic cleverness that some dynamic languages offer in the calling code.)

If you don't want to do that, you are picking the wrong language. Java is a statically typed language, Python is dynamically typed. If you want a dynamic language for a particular job, use a dynamic language. Don't expect a static language to act as a dynamic or vise versa.

Now tell me that ain't useful? Of course it's not something you need everyday (and it might really be bad design in many cases), but there are cases where you want to return two things that are not so closely connected to each other that they really belong into the same class.

I have used it in Python before and it's very useful. I wish Java had this.

First of all, I would like to give you a very basic exam on how to call a method:

String name, int number = getName(someList);

Where did you get that method from when your method defined before was findName(...)?

Besides, you really need to learn what is OO. Even this example is not enough to proof you have enough OO knowledge. Let's say your example is to show that customer name with total number searched. You create an object that wraps these two values and pass it back to the caller until you reach your "View" and show it. This is value object pattern and if you create Frontend application, this becomes, somehow in web sense, your "Model" in "MVC". Tell me, if you have 5 layers (caller methods) between this "findName()" method and the frontend. During development cycle your requirement is changed 3 times for return value to include "long searchedInMilliSeconds, int listSize", you have to change all 5 layers (may be more than 5 caller methods) because they all return multiple values. I don't think this makes any of sense.

In the end, if you like the way of returning multiple values, why do you want "List" as parameter? You simply extract all values from this list, pass them all as parameters like the following:

Well, I am SOO sorry that I once wrote getName und once findName - this was an EXAMPLE, it's likely to make such a mistake if you're writing this stuff into that comment box here...

And don't tell me I don't know about OO. This actually hasn't got anything to do with OO, it's just a tiny, tiny EXAMPLE of why multiple return types CAN actually be useful, or - maybe better - how an actual implementation would look like in Java. Cases where it might actually be useful should be made up by everyone themselves, I think every programmer should have just about enough phantasy to do that.

And yes, it's not useful for EVERY case (remember the sentence: "When you've got a shiny new hammer, every problem looks like a nail"). But there ARE some cases where it is indeed useful.

Python implements that feature. What do you think is the justification for this - widely used - feature in this - widely used - language, if it ain't useful and hasn't got anything to do with OO and and and...

Also, it hasn't got anything to do with type safety (not sure if it was you who mentioned that or someone else), because as you can see in my example, it would be actually VERY typesafe indeed. Because the types "String" and "int" are actually written there. And if you would return some other stuff instead, a good compiler _might_ tell you about that. Yes, Python just returns tuples, but they can be immediately assigned to seperate values (JUST like in my Java example) and if it would be included into a statically typed language, who would claim that it would be necessary to use some kind of Tuple<Object, Object> internally? No one, because it would be bullshit. And I didn't say that either. It would be no problem for static types (JUST like in my Java example).

People should really spend more time with the fundamental parts of computing.

For instance - there is a HUGE cluebyfour in understanding the fundamental parts of LISP (S-expressions).

If someone, for an instance of a second, thought that this was a real problem with Java they should take a break and google up some fundamental LISP-knowledge and be a lot wiser.
As an added benefit you'll understand why those LISP/Scheme nutters (they are, really) are correct when they say that their language is beautiful.

Maybe I better clearify some parts.. Some claiming it is bad design. Could be, but design is always nice in theory but hard in practice. The intention of this article was for cases when multiple values are needed. I agree when implementing some UI, stuff like this is a bloat. But when using (misue) a language like Java for say number crunching algorithms the algorithms are itself messy and hard to read. There is no good design just from the beginning. Asgard gave a example. Do stuff like linear integer programming, data mining and you want multiple return values. One could argue: Why then Java? - use Matlab or Lisp. Yeah sure, I would like to. But sometimes the decisions are not yours to make and you have to reuse stuff your colleagues worked with.