Eclipse - How come Generate Getters and Setters does not consider “By Reference”

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, String s 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.

Answer 2

If the variable is primitive or immutable,you modify what returned won't influence the original property.

Other condition, the variable is a custom type,maybe your class defines a constructor with itself like String,maybe not . So eclipse does not know how to generate it's copy.

As all knows,java pass reference,so java programmers are used to return the reference and allow other modify.Eclipse implement it as default.

If you don't like it ,you can return a copy or implements Immutable.

Answer 3

You usually do not want to create a new object when using getter. What you usually want is to get the reference to object's attribute to work with it easier, for encapsulation and to have the right value even when something else changes the value of the attribute before you use it.

Creating a new instance of an object by method which is called often, is not expected to do it and even does not declare doing such thing is freaking anti-pattern .