Deep Copy

[Emil Jennings]

Hi all,
I know that there have been plenty of question regarding deep copying, but I just don't get it and I'm getting brain fried trying to figure it out. I understand the purpose behind the concept but not how it's done. From what I've read the copy constructor seems to be the best choice, so if I had:

    
public class User { 

	private int uID;	
	private String username;
	private Set<Role> userRoles;

	public User() { }         //default constructor
	
	public User(int uID, String username, Set<Role> userRoles) {	//constructor
		this.uID = uID;
		this.username = username;
		this.userRoles = userRoles;
	}
	
	public User(User originalUser) {	        //copy constructor
		uID = originalUser.getUid();
		username = originalUser.getUserName();
		userRoles = new HashSet<Role> (originalUser.getRoles());
	}

	public int getUid() { return uID; }
	public String getUserName() { return username; }
	public Set<Role> getRoles() { return userRoles;	}
	
	public void setUID(int uID) { this.uID = uID; }
	public void setUserName(String username) { this.username = username; }   
	public void setRoles(Set<Role> userRoles) { this.userRoles = userRoles; } 

}

(and I'm not sure if the copy constructor is correct), how would I use the copy constructor to make deep copies in the getter methods? I know you don't have to for int and String because they're primitive/immutable, but I want to make sure I understand how the deep copy works.

TIA,
GyJ

[Campbell Ritchie]

Welcome to the Ranch

How about this?

public Set<Role> getUserRoles()
{
    return new HashSet<Role>(userRoles);
}//end get user roles

Please maintain full indentation and new lines when you post code; you are on screen not paper, so there is no limit to the number of lines available.
Why have you got a no-args constructor? That appears dangerous because it will allow null values in User objects. Your get and set methods for userRoles are named inappropriately; they should be called getUserRoles and setUserRoles.

[Emil Jennings]

Thanks for the advice Campbell. I made the no-args constructor because at one point the compiler was griping about not having a default constructor and because I was copying an example but whatever code isn't used will be removed.

So let me see if I have this right, if I use

  
public Set<Role> getUserRoles()  
{  
      return new HashSet<Role>(userRoles);  
}//end get user roles  

for the user roles, then theoretically I could also do

  
public int getUid()  
{  
      return new int(uID);  
}//end get user id 

for the user id and

  
public int getUserName()  
{  
      return new String(username);  
}//end get user name

for the user name and that will technically provide deep copies of user id and user name as well, right? And to make sure I have this right, the statements

  
      return new HashSet<Role>(userRoles);  

      return new int(uID);      //Same as return uID; because int is primitive
  
      return new int(username);     //Same as return username; because String is immutable

return a completely new (and different) variable, and the return new HashSet statement is the same as

  
public Set<Role> getUserRoles()  
{  
      Set<Role> ur = new HashSet<Role> (userRoles);
      return ur;  
}//end get user roles  

And if all of the above is true, then it seems to me that the copy constructor is only needed if I wanted to return an object of the User rather than the individual pieces, is that correct and am I starting to see the light at the end of the tunnel (or is it a train)?

Thanks.
GyJ

[Emil Jennings]

Thanks for the advice Campbell. I made the no-args constructor because at one point the compiler was griping about not having a default constructor and because I was copying an example but whatever code isn't used will be removed.

So let me see if I have this right, if I use

  
public Set<Role> getUserRoles()  
{  
      return new HashSet<Role>(userRoles);  
}//end get user roles  

for the user roles, then theoretically I could also do

  
public int getUid()  
{  
      return new int(uID);  
}//end get user id 

for the user id and

  
public int getUserName()  
{  
      return new String(username);  
}//end get user name

for the user name and that will technically provide deep copies of user id and user name as well, right? And to make sure I have this right, the statements

  
      return new HashSet<Role>(userRoles);  

      return new int(uID);      //Same as return uID; because int is primitive
  
      return new int(username);     //Same as return username; because String is immutable

return a completely new (and different) variable, and the return new HashSet statement is the same as

  
public Set<Role> getUserRoles()  
{  
      Set<Role> user = new HashSet<Role> (userRoles);
      return user;  
}//end get user roles  

And if all of the above is true, then it seems to me that the copy constructor is only needed if I wanted to return an object of the User rather than the individual pieces, is that correct and am I starting to see the light at the end of the tunnel (or is it a train)? To be sure, if I did

 
public Set<Role> getRoles() { 
     Set<Role> user = new HashSet<Role> (userRoles);
     System.out.println("userRoles = " + userRoles + ", user = " + user);
     return user; 
}

would that show user and userRoles at different addresses?
Thanks.
GyJ

[Rob Spoor]

I prefer to return Collections.unmodiableSet(userRoles) mostly. That doesn't copy all elements, but still disallows modification from outside. If calling code then needs a copy they can do that themselves:

Set<Role> roles = new HashSet<Role>(instance.getUserRoles());

I of course specify in the Javadocs that the returned Set is unmodifiable.

[Emil Jennings]

I'm expecting a deep copy that does

    
public Set<Role> getRoles() 
{ 
     System.out.println("userRoles = " + userRoles);

     Set<Role> roles = new HashSet<Role>(userRoles);

     System.out.println("    roles = " + roles);

     return roles;
}

Would display something like

    
userRoles = [com.hibernate.login.Role@180cf2a, com.hibernate.login.Role@8ae45a]
    roles = [com.hibernate.login.Role@290ff9a, com.hibernate.login.Role@6bc31d]

instead of

userRoles = [com.hibernate.login.Role@180cf2a, com.hibernate.login.Role@8ae45a]
    roles = [com.hibernate.login.Role@180cf2a, com.hibernate.login.Role@8ae45a]

Doesn't the identical values indicate that this is a shallow copy?

Thanks.

[Rob Spoor]

You'll need to deep copy your roles as well:

Set<Role> roles = new HashSet<Role>(userRoles.size());  // no initial contents
for (Role role: userRoles)
{
    Role copy = ...;
    roles.add(copy);
}

[Emil Jennings]

Thanks Rob, but since I'm still at a loss what goes at ... ? I've been trying variations of .add but I keep coming up with the same results of a shallow copy.

[Rob Spoor]

Since I can't find any class called com.hibernate.login.Role I can't help you with that. The only occurrence of it on Google is this thread! And I also cannot find any class called Role in the entire Hibernate API.

[Emil Jennings]

Actually, your response did help. And I now have the deep copied results. Thanks a lot, but I must ask...what is the advantage of passing by reference when it seems that passing by value is more desirable in regards to data protection?

[Rob Spoor]

Sometimes you don't need to protect your data like that. The Map returned by ProcessBuilder.environment() is such an example - you change the environment by modifying this Map directly.

[Emil Jennings]

OK. Thanks a bunch for everyone's help I appreciate it.

[Campbell Ritchie]

What's passing by reference? Java™ doesn't support pass-by-reference.

[Emil Jennings]

I've seen enough about the Java only passes by value, no passing by reference, so I'll answer with the below quote from Murach's Java SE 6, Joel Murach and Andrea Steelman, 2007, Mike Murach & Associates, Inc. pp 200-201:

Figure 6-12 shows that primitive type are passed to a method one way, while reference types (objects) are passed another way. Specifically, primitive types are passed by value, which means that a copy of the value is passed, not the value itself. In contrast, objects are passed by reference, which means that a pointer to the object is passed. Because of that, the method knows where the object's variables are so it can change them directly.

Figure 6-12:
Example 1: Primitive types are passed by value

    
static double increasePrice (double price)   // returns a double
{
     return price *= 1.1;
}

Code that calls the method

    
double price = 49.5;
price = increasePrice(price);   //reassignment statement
System.out.println("price: " + price);

Result

    
price: 54.45

Example 2: Objects are passed by reference

    
static void increasePrice(Product product)       //no return value
{
     double price = product.getPrice();
     product,setPrice(price *= 1.1);
}

Code that calls the method

    
Product product = ProductDB.getProduct("java");
System.out.println("product.getPrice(): " + product.getPrice());
increasePrice(product);                           //no reassignment necessary
System.out.println("product.getPrice(): " + product.getPrice());

Result

    
product.getPrice(): 49.5
product.getPrice(): 54.45

Description:
When a primitive type is passed to a method, it is passed by value. That means the method can't change the value of the variable itself. Instead, the method must return a new value that gets stored in the variable.
When a reference type (an object) is passed to a method, it is passed by reference. That means that the method can change the data in the object itself, so a new value doesn't need to be returned by the method.

[Rob Spoor]

Gunny Jennings wrote:Example 2: Objects are passed by reference

No they aren't. Or at least, the reference is being passed by value. http://faq.javaranch.com/java/CallByReferenceVsCallByValue

[Campbell Ritchie]

Gunny Jennings wrote: . . .
Description:
When a primitive type is passed to a method, it is passed by value. That means the method can't change the value of the variable itself. Instead, the method must return a new value that gets stored in the variable.
When a reference type (an object) is passed to a method, it is passed by reference. That means that the method can change the data in the object itself, so a new value doesn't need to be returned by the method.

Murach are capable of far better than that.

That's nonsense. Everything is passed by value. If it were pass-by-reference you could change the actual object. You can't. It is pass-by-value so you can't change the object, but you can manipulate it (ie change its state).
Start with this link, and do a search through these fora for pass by reference and pass by value. You will find threads like this one where we spent hours and hours trying to demonstrate the difference.