Multiple return values (Bug-ID 4222792)

Question

I had exactly the same request for the same 3 reasons: strong type safety and code correctness verification at compile-time, code readability and ease of mantenance, performance.
Here is what Sun replied to me:
Autoboxing and varargs are provided as part of
JSRs 14 and 201
http://jcp.org/en/jsr/detail?id=14
http://jcp.org/en/jsr/detail?id=201
See also:
http://forum.java.sun.com/forum.jsp?forum=316
http://developer.java.sun.com/developer/earlyAccess/adding_generics/index.html
Multiple return values is covered by Bug-ID 4222792
Typically this is done by returning an array.
http://developer.java.sun.com/developer/bugParade/bugs/4222792.html
That's exactly the problem: we dynamically create instances of array objects that would better fit well within the operand stack without stressing the garbage collector with temporary Array object instances (and with their backing store: 2 separate allocations that need to be recycled when it is clearly a pollution that the operand stack would clean up more efficiently)
If you would like to engage in a discussion with the Java Language developers, the Generics forum would be a better place:
http://forum.java.sun.com/forum.jsp?forum=316
I know that (my report was already refering to the JSR for language extension) Generics is not what I was refering to (even if a generic could handle multiple return values, it would still be an allocated Object
instance to pack them, i.e. just less convenient than using a static class for type safety.
The most common case of multiple return values involve values that have known static datatypes and that should be checked with strong typesafety.
The simple case that involves returning two ints then will require at least two object instances and will not solve the garbage collection overhead.
Using a array of variable objects is exactly similar, except that it requires two instances for the components and one instance for the generic array container. Using extra method parameters with Integer, Byte, ... boxing objects is more efficient, but for now the only practical solution (which causes the least pollution in the VM allocator and garbage collector) is to use a custom class to store the return values in a single instance.
This is not natural, and needlessly complexifies many interfaces.
So to avoid this pollution, some solutions are used such as packing two ints into a long and returning a long, depacking the long after return (not quite clean but still much faster at run-time for methods that need to be used with high frequencies within the application. In some case, the only way to cut down the overhead is to inline methods within the caller code, and this does not help code maintenance by splitting the implementation into small methods (something that C++ can do very easily, both because it supports native types parameters by reference, and because it also supports inline methods).
Finally, suppose we don't want to use tricky code, difficult to maintain, then we'll have to use boxing Object types to allow passing arguments by reference. Shamely boxed native types cannot be allocated on the operand stack as local variables, so we need to instanciate these local variables before call, and we loose the capacity to track the cases where these local variables are not really initialized by an effective call to the method that will assign them. This does not help debugging, and is against the concept of a strongly typed language like Java should be:
Java makes lots of efforts to track uninitialized variables, but has no way to determine if an already instanciated Object instance refered in a local variable has effectively received an effective assignment because only the instanciation is kept. A typical code will then need to be written like this:
Integer a = null;
Integer b = null;
if (some condition) {
//call.method(a, b, 0, 1, "dummy input arg");
// the method is supposed to have assigned a value to a and b,
// but can't if a and b have not been instanciated, so we perform:
call.method(a = new Integer(), b = new Integer(), 0, 1, "dummy input
arg");
// we must suppose that the method has modified (not initialized!)
the value
// of a and b instances.
now.use(a.value(), b.value())
// are we sure here that a and b have received a value????
// the code may be detected at run-time (a null exception)
// or completely undetected (the method() above was called but it
// forgot to assign a value to its referenced objects a and b, in which
// case we are calling in fact: now.use(0, 0); with the default values
// or a and b, assigned when they were instanciated)
Very tricky... Hard to debug. It would be much simpler if we just used:
int a;
int b;
if (some condition) {
(a, b) = call.method(0, 1, "dummy input arg");
now.use(a, b);
The compiler would immediately detect the case where a and b are in fact not always initialized (possible use bere initialization), and the first invoked call.method() would not have to check if its arguments are not null, it would not compile if it forgets to return two values in some code path...
There's no need to provide extra boxing objects in the source as well as at run-time, and there's no stress added to the VM allocator or garbage collector simply because return values are only allocated on the perand stack by the caller, directly instanciated within the callee which MUST (checked at compile-time) create such instances by using the return statement to instanciate them, and the caller now just needs to use directly the variables which were referenced before call (here a and b). Clean and mean. And it allows strong typechecking as well (so this is a real help for programmers.
Note that the signature of the method() above is:
class call {
(int, int) method(int, int, String) { ... }
id est:
class "call", member name "method", member type "(IILjava.lang.string;)II"
This last signature means that the method can only be called by returning the value into a pair of variables of type int, or using the return value as a pair of actual arguments for another method call such as:
call.method(call.method("dummy input arg"), "other dummy input arg")
This is strongly typed and convenient to write and debug and very efficient at run-time...

Answer 1

Can anyone give me some real-world examples where
multiple return values aren't better captured in a
class that logically groups those values? I can of
course give hundreds of examples for why it's better
to capture method arguments as multiple values instead
of as one "logical object", but whenever I've hankered
for multiple return values, I end up rethinking my
strategy and rewriting my code to be better Object
Oriented.I'd personally say you're usually right. There's almost always a O-O way of avoiding the situation.
Sometimes though, you really do just want to return "two ints" from a function. There's no logical object you can think of to put them in. So you end up polluting the namespace:
public class MyUsefulClass {
public TwoInts calculateSomething(int a, int b, int c) {
public static class TwoInts {
    //now, do I use two public int fields here, making it
    //in essence a struct?
   //or do I make my two ints private & final, which
   //requires a constructor & two getters?
  //and while I'm at it, is it worth implementing
  //equals(), how about hashCode()? clone()?
  //readResolve() ?
}The answer to most of the questions for something as simple as "TwoInts" is usually "no: its not worth implementing those methods", but I still have to think about them.
More to the point, the TwoInts class looks so ugly polluting the top level namespace like that, MyUsefulClass.TwoInts is public, that I don't think I've ever actually created that class. I always find some way to avoid it, even if the workaround is just as ugly.
For myself, I'd like to see some simple pass-by-value "Tuple" type. My fear is it'd be abused as a way for lazy programmers to avoid creating objects when they should have a logical type for readability & maintainability.
Anyone who has maintained code where someone has passed in all their arguments as (mutable!) Maps, Collections and/or Arrays and "returned" values by mutating those structures knows what a nightmare it can be. Which I suppose is an argument that cuts both ways: on the one hand you can say: "why add Tuples which would be another easy thing to abuse", on the other: "why not add Tuples, given Arrays and the Collections framework already allow bad programmers to produce unmainable mush. One more feature isn't going to make a difference either way".
Ho hum.