How to return multiple objects from a Java method?

If you want to return two objects you usually want to return a single object that encapsulates the two objects instead.

You could return a List of NamedObject objects like this:

public class NamedObject<T> {
  public final String name;
  public final T object;

  public NamedObject(String name, T object) {
    this.name = name;
    this.object = object;
  }
}

Then you can easily return a List<NamedObject<WhateverTypeYouWant>>.

Also: Why would you want to return a comma-separated list of names instead of a List<String>? Or better yet, return a Map<String,TheObjectType> with the keys being the names and the values the objects (unless your objects have specified order, in which case a NavigableMap might be what you want.

If you know you are going to return two objects, you can also use a generic pair:

public class Pair<A,B> {
    public final A a;
    public final B b;

    public Pair(A a, B b) {
        this.a = a;
        this.b = b;
    }
};

Edit A more fully formed implementation of the above:

package util;

public class Pair<A,B> {

    public static <P, Q> Pair<P, Q> makePair(P p, Q q) {
        return new Pair<P, Q>(p, q);
    }

    public final A a;
    public final B b;

    public Pair(A a, B b) {
        this.a = a;
        this.b = b;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((a == null) ? 0 : a.hashCode());
        result = prime * result + ((b == null) ? 0 : b.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
        if (obj == null) {
            return false;
        }
        if (getClass() != obj.getClass()) {
            return false;
        }
        @SuppressWarnings("rawtypes")
        Pair other = (Pair) obj;
        if (a == null) {
            if (other.a != null) {
                return false;
            }
        } else if (!a.equals(other.a)) {
            return false;
        }
        if (b == null) {
            if (other.b != null) {
                return false;
            }
        } else if (!b.equals(other.b)) {
            return false;
        }
        return true;
    }

    public boolean isInstance(Class<?> classA, Class<?> classB) {
        return classA.isInstance(a) && classB.isInstance(b);
    }

    @SuppressWarnings("unchecked")
    public static <P, Q> Pair<P, Q> cast(Pair<?, ?> pair, Class<P> pClass, Class<Q> qClass) {

        if (pair.isInstance(pClass, qClass)) {
            return (Pair<P, Q>) pair;
        }

        throw new ClassCastException();

    }

}

Notes, mainly around rustiness with Java & generics:

• both a and b are immutable.
• makePair static method helps you with boiler plate typing, which the diamond operator in Java 7 will make less annoying. There's some work to make this really nice re: generics, but it should be ok-ish now. (c.f. PECS)
• hashcode and equals are generated by eclipse.
• the compile time casting in the cast method is ok, but doesn't seem quite right.
• I'm not sure if the wildcards in isInstance are necessary.
• I've just written this in response to comments, for illustration purposes only.

I almost always end up defining n-Tuple classes when I code in Java. For instance:

public class Tuple2<T1,T2> {
  private T1 f1;
  private T2 f2;
  public Tuple2(T1 f1, T2 f2) {
    this.f1 = f1; this.f2 = f2;
  }
  public T1 getF1() {return f1;}
  public T2 getF2() {return f2;}
}

I know it's a bit ugly, but it works, and you just have to define your tuple types once. Tuples are something Java really lacks.

EDIT: David Hanak's example is more elegant, as it avoids defining getters and still keeps the object immutable.

Before Java 5, I would kind of agree that the Map solution isn't ideal. It wouldn't give you compile time type checking so can cause issues at runtime. However, with Java 5, we have Generic Types.

So your method could look like this:

public Map<String, MyType> doStuff();

MyType of course being the type of object you are returning.

Basically I think that returning a Map is the right solution in this case because that's exactly what you want to return - a mapping of a string to an object.

Alternatively, in situations where I want to return a number of things from a method I will sometimes use a callback mechanism instead of a container. This works very well in situations where I cannot specify ahead of time just how many objects will be generated.

With your particular problem, it would look something like this:

public class ResultsConsumer implements ResultsGenerator.ResultsCallback
{
    public void handleResult( String name, Object value )
    {
        ... 
    }
}

public class ResultsGenerator
{
    public interface ResultsCallback
    {
        void handleResult( String aName, Object aValue );
    }

    public void generateResults( ResultsGenerator.ResultsCallback aCallback )
    {
        Object value = null;
        String name = null;

        ...

        aCallback.handleResult( name, value );
    }
}

All possible solutions will be a kludge (like container objects, your HashMap idea, “multiple return values” as realized via arrays). I recommend regenerating the comma-separated list from the returned List. The code will end up being a lot cleaner.

Keep it simple and create a class for multiple result situation. This example accepts an ArrayList and a message text from a databasehelper getInfo.

Where you call the routine that returns multiple values you code:

multResult res = mydb.getInfo(); 

In the routine getInfo you code:

ArrayList<String> list= new ArrayList<String>();
add values to the list...
return new multResult("the message", list);

and define a class multResult with:

public class multResult {
    public String message; // or create a getter if you don't like public
    public ArrayList<String> list;
    multResult(String m, ArrayList<String> l){
        message = m;
        list= l;
}

}

As I see it there are really three choices here and the solution depends on the context. You can choose to implement the construction of the name in the method that produces the list. This is the choice you've chosen, but I don't think it is the best one. You are creating a coupling in the producer method to the consuming method that doesn't need to exist. Other callers may not need the extra information and you would be calculating extra information for these callers.

Alternatively, you could have the calling method calculate the name. If there is only one caller that needs this information, you can stop there. You have no extra dependencies and while there is a little extra calculation involved, you've avoided making your construction method too specific. This is a good trade-off.

Lastly, you could have the list itself be responsible for creating the name. This is the route I would go if the calculation needs to be done by more than one caller. I think this puts the responsibility for the creation of the names with the class that is most closely related to the objects themselves.

In the latter case, my solution would be to create a specialized List class that returns a comma-separated string of the names of objects that it contains. Make the class smart enough that it constructs the name string on the fly as objects are added and removed from it. Then return an instance of this list and call the name generation method as needed. Although it may be almost as efficient (and simpler) to simply delay calculation of the names until the first time the method is called and store it then (lazy loading). If you add/remove an object, you need only remove the calculated value and have it get recalculated on the next call.

In C++ (STL) there is a pair class for bundling two objects. In Java Generics a pair class isn't available, although there is some demand for it. You could easily implement it yourself though.

I agree however with some other answers that if you need to return two or more objects from a method, it would be better to encapsulate them in a class.

Why not create a WhateverFunctionResult object that contains your results, and the logic required to parse these results, iterate over then etc. It seems to me that either:

1. These results objects are intimately tied together/related and belong together, or:
2. they are unrelated, in which case your function isn't well defined in terms of what it's trying to do (i.e. doing two different things)

I see this sort of issue crop up again and again. Don't be afraid to create your own container/result classes that contain the data and the associated functionality to handle this. If you simply pass the stuff around in a HashMap or similar, then your clients have to pull this map apart and grok the contents each time they want to use the results.

You can utilize a HashMap<String, Object> as follows

public HashMap<String, Object> yourMethod()
{

   .... different logic here 

  HashMap<String, Object> returnHashMap = new HashMap<String, Object>();
  returnHashMap.put("objectA", objectAValue);
  returnHashMap.put("myString", myStringValue);
  returnHashMap.put("myBoolean", myBooleanValue);

  return returnHashMap;
}

Then when calling the method in a different scope, you can cast each object back to its initial type:

// call the method
HashMap<String, Object> resultMap = yourMethod();
                
// fetch the results and cast them
ObjectA objectA = (ObjectA) resultMap.get("objectA");
String myString = (String) resultMap.get("myString");
Boolean myBoolean = (Boolean) resultMap.get("myBoolean");

I noticed there is no no-custom class, n-length, no-cast, type-safe answers yet to returning multiple values.

Here is my go:

import java.util.Objects;

public final class NTuple<V, T extends  NTuple<?, ?>> {
    private final V value;
    private final T next;

    private NTuple(V value, T next) {
        this.value = value;
        this.next = next;
    }

    public static <V> NTuple<V, ?> of(V value) {
        return new NTuple<>(value, null);
    }

    public static <V,  T extends  NTuple<?, ?>> NTuple<V, T> of(V value, T next) {
        return new NTuple<>(value, next);
    }

    public V value() {
        return value;
    }

    public T next() {
        return next;
    }

    public static <V> V unpack0(NTuple<V, ?> tuple) {
        return Objects.requireNonNull(tuple, "0").value();
    }

    public static <V, T extends NTuple<V, ?>> V unpack1(NTuple<?, T> tuple) {
        NTuple<?, T> tuple0 = Objects.requireNonNull(tuple, "0");
        NTuple<V, ?> tuple1 = Objects.requireNonNull(tuple0.next(), "1");
        return tuple1.value();
    }

    public static <V, T extends NTuple<?, NTuple<V, ?>>> V unpack2(NTuple<?, T> tuple) {
        NTuple<?, T> tuple0 = Objects.requireNonNull(tuple, "0");
        NTuple<?, NTuple<V, ?>> tuple1 = Objects.requireNonNull(tuple0.next(), "1");
        NTuple<V, ?> tuple2 = Objects.requireNonNull(tuple1.next(), "2");
        return tuple2.value();
    }
}

Sample use:

public static void main(String[] args) {
    // pre-java 10 without lombok - use lombok's var or java 10's var if you can
    NTuple<String, NTuple<Integer, NTuple<Integer, ?>>> multiple = wordCount("hello world");
    String original = NTuple.unpack0(multiple);
    Integer wordCount = NTuple.unpack1(multiple);
    Integer characterCount  = NTuple.unpack2(multiple);

    System.out.println(original + ": " + wordCount + " words " + characterCount + " chars");
}

private static NTuple<String, NTuple<Integer, NTuple<Integer, ?>>> wordCount(String s) {
    int nWords = s.split(" ").length;
    int nChars = s.length();
    return NTuple.of(s, NTuple.of(nWords, NTuple.of(nChars)));
}

Pros:

• no-custom container class - no need to write a class just for a return type
• n-length - can handle any number of return values
• no-cast - no need to cast from Object
• type-safe - the types are checked via Java's generics

Cons:

• inefficient for large numbers of return values
  • according to my experience with python's multiple return values, this should not happen in practice
• heavy type declarations
  • can be alleviated by lombok/Java 10 var

PASS A HASH INTO THE METHOD AND POPULATE IT......

public void buildResponse(String data, Map response);