How to create IN OUT or OUT parameters in Java

Question

In PL/SQL (or many other languages), I can have IN OUT or OUT parameters, which are returned from a procedure. How can I achieve a similar thing in Java?

I know this trick:

public void method(String in, String[] inOut, String[] inOut2) {
  inOut[0] = in;
}

Where the in parameter represents an IN parameter and the inOut parameter can hold a return value. The convention would be that String[] inOut is an array of inOut.length == 1.

That's kind of clumsy.

EDIT Feedback to answers: Other tricks include:

• holder/wrapper classes, but I don't want to introduce any new types, callbacks, etc.
• return values: I'd like a general solution. I.e. one with several IN OUT parameters involved.
• wrapper for IN OUT parameter as a return value: That's a viable option, but still not so nice, because that wrapper would have to be generated somehow

Does anyone know a better way to achieve this generally? The reason I need a general solution is because I want to generate convenience source code from PL/SQL in a database schema.

Answer 1

My question would be: Why doesn't method return something? Rather than setting an in/out argument?

But assuming you absolutely, positively must have an in/out argument, which is a whole different question, then the array trick is fine. Alternately, it's not less clumsy, but the other way is to pass in an object reference:

public class Foo {
    private String value;

    public Foo(String v) {
        this.value = v;
    }

    public String getValue() {
        return this.value;
    }

    public void setValue(String v) {
        this.value = v;
    }
 }

 // ....
 public void method(String in, Foo inOut) {
     inOut.setValue(in);
 }

(Or, of course, just make value public.) See? I said it wasn't less clumsy.

But I'd ask again: Can't method return something? And if it needs to return multiple things, can't it return an object instance with properties for those things?

Off-topic: This is one of the areas where I really like the C# approach. One of the arguments against in/out arguments is that they're unclear at the point where you're calling the function. So C# makes you make it clear, by specifying the keyword both at the declaration of the function and when calling it. In the absense of that kind of syntactic help, I'd avoid "simulating" in/out arguments.