Question

if java is always pass variables by reference, why does eclipse generate the bean with out any consideration.

instead of:
return myStr;

needs to be
return new String(myStr);

no?

Edit
Ok, my example was bad.
lets leave eclipse, When I want to return a Custom object. Do i need to create a “copy constructor” and return it, like that:

return new MyCustomObject(myCustomObject);


class MyCustomObject{

  private String str; 
  public MyCustomObject(String str){
    this.str = str;
  }

  public MyCustomObject(MyCustomObject obj){
    this.str =  obj.str;    
  }
}

Must I write that?

Answer 1

No.

In Java, every object variable is a reference. Objects cannot be passed by value, only primitives can (and always are). Well, that’s slightly misleading. The reference is passed by value, but you can think of everything being a reference, just not in a C++ sense.

Perhaps it’s easiest to use an example.

SomeObject foo;

public void doSomething(SomeObject bar) {
    bar.whatever();
    bar = new SomeObject();
    bar.someOtherMethod();
}

public void doStuff() {
    foo = new SomeObject();
    doSomething(foo);
}

So, foo is a reference to an instance of SomeObject. When doSomething is called, the value of that reference is copied to bar, so now foo and bar are references to the same SomeObject.

The line bar.whatever() calls whatever on the same object that foo refers to.

bar = new SomeObject() means that foo and bar now refer to different SomeObject instances, so someOtherMethod is not called on the object that foo refers to.

This is completely different to C++, where

void doSomething(SomeObject& bar) {
    bar = whatever;
}

has a totally different meaning. You really should not ever think of Java in C++ terms.

Regarding your example, Strings are immutable in Java so it wouldn’t matter even if objects could be passed by value.

Regarding your second example, if you want to return an object that the caller cannot use to pollute your internal state then, yes, you need to have a copy constructor (or something equivalent).

For example:

class ClassWithInternalList {
    private List<String> reallyImportantData;

    public List<String> getImmutableViewOfData() {
        // Take advantage of the java.util.Collections tool for making a List immutable.
        return Collections.unmodifiableList(reallyImportantData);
    }

    public List<String> getSafeCopyOfData() {
        // Return a copy that the caller can modify without changing reallyImportantData.
        return new ArrayList<String>(reallyImportantData);
    }

    public List<String> justGetTheData() {
        // Return a reference to reallyImportantData that the caller can modify at will.
        return reallyImportantData;
    }
}

You can choose the appropriate type of return value (normal reference, immutable view or copy) depending on the situation. Any or all of the three options could be appropriate depending on exactly what you are doing.

java.util.Collections makes it easy to get an immutable view of a Collection, but for custom classes you’ll need to do your own immutable-ness.

Remember that you only need to do this if there is an issue with mutability. Your MyCustomObject example is still immutable (since the caller cannot change any state in the returned MyCustomObject instance), so the question is still kinda moot.