For starters, try to stop thinking in C++ - easier said than done
admittedly, but worth it.

In Java, References are passed by value. The objects they point to
aren't actually moved or copied at all.

Primitives (ints, boolean, long, etc) are always passed by value.

So this leaves only two ways of returning things from methods.

1) the method's returned type.  In your example, you could change the
method signature to return something rather than its current 'void'.

2) Pass in a reference to a Data holder object, inside the method set
the value within the Dataholder to what ever it is you want to return.

Either way works for sending by single or multiple values. For multiple
values it just means you'll have to wrap then in something.

Data holder passed in parameter list example:

class StuffReturnedByMethod2 (
 String [] sa1 = null; // to be created and returned by method2
 String s2 = null; // to be created and returned by method2
}

public boolean method1 (String s1, other args)
{
 //do some stuff
 StuffReturnedByMethod2 returnedStuff = new StuffReturnedByMethod2();
 Method2(s1, returnedStuff )

 //do some important stuff with sa1 and s2

 String[] sa1 = returnedStuff.sa1;
 String s2 = returnedStuff.s2;

 return true;
 }

 // C++ type method (unfortunately)
 private void method2 (String s1, StuffReturnedByMethod2 stuffToReturn)
 {
 //do some stuff
 StringTokenizer st = new StringTokenizer(s1, "/");

 String sRemainder = st.nextToken();
 stuffToReturn.s2 = st.nextToken(); // just a string to be returned

 stuffToReturn.sa1 = sRemainder.split(",");
// a string array to be returned
 }

This might look - hacky or cheap, but what we tend to find, is that we
have more smaller classes in Java, which are highly focused upon one
job. These classes might startout being mere data holders, but usually,
very quickly they start attracting behaviour or state too.

What you're actually after is multiple return values ("return a String and
a new String array" => two return values). Unfortunately Java provides no
efficient construct for multiple return values. They were removed before
the first release of Java. I'd like to locate the 1997 interview
referenced in this Usenet post:
<http://groups.google.com/group/comp.object/msg/580bc83193356221?dmode=source>

  Gosling may just be being folksy, but I find the following
  answers from a language designer as really poor:

  G:> Yeah. I actually had an implementation of Mesa-style
  G:> multiple value returns mostly implemented just before
  G:> 1.0 that I ripped out because I was uncomfortable with
  G:> the semantics, and the schedule was getting tight.
  G:> Right now, I really regret it.

The next thing you may try to do with a language that doesn't implement
multiple return values is pass the values upon the stack via a pointer.
This will be less efficient than multiple return values passed in
registers but more efficient than heap-allocated multiple return values.
This approach is also impossible in Java.

This leaves building an object to pass the values in. You have the choice
of whether the caller should pass an object for the callee to mutate or
whether the callee builds a fresh object to hold the multiple return
values.

You may be inclined to pass a container object to the callee to mutate
since the container can be reused by the caller. I suggest the callee
should build a new container for multiple values each time because the
most sophisticated JVMs will soon be able to avoid heap allocation (and
perhaps even stack allocation) via escape analysis. Thus we are close to
the point where Gosling's omission of explicit multiple return values will
no longer be a hindrance to efficiently returning multiple values. While
your code is likely to run slower in the meantime it's the future-proof
option.

Regards,
Adam

Thanks very much for your comments and advice. It's been a long day
(about 12 straight hours coding) so I'll try using your suggested "reply
class" or "return class" tomorrow.  Though I can't imagine having
trouble with that method.

If there's any trouble (which I doubt) I'll post it back on this thread.

Thanks again

Lenny Wintfeld

Lenny Wintfeld sez:

Yes, but Java's fscked-up terminology takes large portion of the
blame. In Java "reference values" are pointers passed by value.
Assignment operator simply re-points the pointer (not like C++
references), whereas dereferencing operator does what you
expect: e.g. you can modify the object by calling its mutator
methods (not like "pass by value").

Simple for sa1:
String [] sa1 = new String[N];
(provided N is known beforehand, otherwise use ArrayList). For s2
the trick is that strings are "immutable" (have no mutator methods),
so you need to use a mutable version: StringBuilder (1.5+ only) or
StringBuffer:
StringBuilder s2 = new StringBuilder();

Creating a separate class for return value only makes sense where
you'd return a struct in C++. In this case I'd probably not bother
anyway : you can as easily return s2 as 1st element of your array.

Dima

Why not just pass is back as the return value? You are using your
return value's right now for error handling(I am assuming that's what
the true/false return would be used for). Java and C++ have this
wonderful thing called Exceptions. If you look at your false return
situations and think "Hey, this would only return false in a few
exceptional cases", then you have an exception. If you have a situation
where you think "Hey, this is going to return false a lot under normal
circumstances", then you need to refactor.