Well, it’s redundant. Here’s why.

There are two approaches to doing this – the classic way (caller chooses what to manipulate/change), and callee changes (which is what happens when you pass in an object by reference:

• If the caller chooses what to manipulate, then your method will operate on a copy of the dataset, and return that copy, leaving the original untouched. Then the caller may overwrite the original, if desired. Many array operations in Perl work like this.
• The alternative lets the called method do the in-place operation, in which case the return value is more typically a boolean (”Yes, I’ve succeeded!”) or an int containing the number of values affected. This is how database updates work.

Of course, if the object is not passed by reference (i.e. a copy is passed into the method) or if the method explicitly returns a modified copy, then returning an object is the right way to do it.

Java applications can only be run on a machine with a JRE (Java Runtime Environment), so any setup utility won’t run quite the same as other application setup files; you won’t be able to give someone your setup file and expect it to run correctly, unless they already have the appropriate JRE.

It is still possible to install Java applications using standard Windows Installer utilities; some tools allow you to bundle (or download and install) a suitable JRE as part of the Windows Installer process, resulting in the application’s files being installed along with any dependencies.

It’s even possible to install Java applications as a service in Windows, using additional wrapper utilities.

However, in Java, the usual way to do the “setup routine” is typically going to result in a “jar” file. This way, you can launch the program by using a shortcut that launches the JVM and points it to the appropriate jar file. From the user’s point of view, this is indistinguishable from any other shortcut, but of course it requires that the files and JRE have already been installed.