Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Thinking in Java
Prev Contents / Index Next

Assignment

Assignment is performed with the operator =. It means “take the value of the right-hand side (often called the rvalue) and copy it into the left-hand side (often called the lvalue).” An rvalue is any constant, variable, or expression that can produce a value, but an lvalue must be a distinct, named variable. (That is, there must be a physical space to store the value.) For instance, you can assign a constant value to a variable:

a = 4;


but you cannot assign anything to constant value—it cannot be an lvalue. (You can’t say 4 = a;.)

Assignment of primitives is quite straightforward. Since the primitive holds the actual value and not a reference to an object, when you assign primitives, you copy the contents from one place to another. For example, if you say a = b for primitives, then the contents of b are copied into a. If you then go on to modify a, b is naturally unaffected by this modification. As a programmer, this is what you’ve come to expect for most situations.

When you assign objects, however, things change. Whenever you manipulate an object, what you’re manipulating is the reference, so when you assign “from one object to another,” you’re actually copying a reference from one place to another. This means that if you say c = d for objects, you end up with both c and d pointing to the object that, originally, only d pointed to. Here’s an example that demonstrates this behavior:

//: c03:Assignment.java
// Assignment with objects is a bit tricky.
import com.bruceeckel.simpletest.*;

class Number {
  int i;
}

public class Assignment {
  static Test monitor = new Test();
  public static void main(String[] args) {
    Number n1 = new Number();
    Number n2 = new Number();
    n1.i = 9;
    n2.i = 47;
    System.out.println("1: n1.i: " + n1.i +
      ", n2.i: " + n2.i);
    n1 = n2;
    System.out.println("2: n1.i: " + n1.i +
      ", n2.i: " + n2.i);
    n1.i = 27;
    System.out.println("3: n1.i: " + n1.i +
      ", n2.i: " + n2.i);
    monitor.expect(new String[] {
      "1: n1.i: 9, n2.i: 47",
      "2: n1.i: 47, n2.i: 47",
      "3: n1.i: 27, n2.i: 27"
    });
  }
} ///:~


First, notice that something new has been added. The line:

import com.bruceeckel.simpletest.*;


imports the “simpletest” library that has been created to test the code in this book, and is explained in Chapter 15. At the beginning of the Assignment class, you see the line:

  static Test monitor = new Test();


This creates an instance of the simpletest class Test, called monitor. Finally, at the end of main( ), you see the statement:

    monitor.expect(new String[] {
      "1: n1.i: 9, n2.i: 47",
      "2: n1.i: 47, n2.i: 47",
      "3: n1.i: 27, n2.i: 27"
    });


This is the expected output of the program, expressed as an array of String objects. When the program is run, it not only prints out the output, but it compares it to this array to verify that the array is correct. Thus, when you see a program in this book that uses simpletest, you will also see an expect( ) call that will show you what the output of the program is. This way, you see validated output from the program.

The Number class is simple, and two instances of it (n1 and n2) are created within main( ). The i value within each Number is given a different value, and then n2 is assigned to n1, and n1 is changed. In many programming languages you would expect n1 and n2 to be independent at all times, but because you’ve assigned a reference, you’ll see the output in the expect( ) statement. Changing the n1 object appears to change the n2 object as well! This is because both n1 and n2 contain the same reference, which is pointing to the same object. (The original reference that was in n1, that pointed to the object holding a value of 9, was overwritten during the assignment and effectively lost; its object will be cleaned up by the garbage collector.)

This phenomenon is often called aliasing, and it’s a fundamental way that Java works with objects. But what if you don’t want aliasing to occur in this case? You could forego the assignment and say:

n1.i = n2.i;


This retains the two separate objects instead of tossing one and tying n1 and n2 to the same object, but you’ll soon realize that manipulating the fields within objects is messy and goes against good object-oriented design principles. This is a nontrivial topic, so it is left for Appendix A, which is devoted to aliasing. In the meantime, you should keep in mind that assignment for objects can add surprises.

Aliasing during method calls

Aliasing will also occur when you pass an object into a method:

//: c03:PassObject.java
// Passing objects to methods may not be what
// you're used to.
import com.bruceeckel.simpletest.*;

class Letter {
  char c;
}

public class PassObject {
  static Test monitor = new Test();
  static void f(Letter y) {
    y.c = 'z';
  }
  public static void main(String[] args) {
    Letter x = new Letter();
    x.c = 'a';
    System.out.println("1: x.c: " + x.c);
    f(x);
    System.out.println("2: x.c: " + x.c);
    monitor.expect(new String[] {
      "1: x.c: a",
      "2: x.c: z"
    });
  }
} ///:~


In many programming languages, the method f( ) would appear to be making a copy of its argument Letter y inside the scope of the method. But once again a reference is being passed, so the line

y.c = 'z';


is actually changing the object outside of f( ). The output in the expect( ) statement shows this.

Aliasing and its solution is a complex issue and, although you must wait until Appendix A for all the answers, you should be aware of it at this point so you can watch for pitfalls.
Thinking in Java
Prev Contents / Index Next


 
 
   Reproduced courtesy of Bruce Eckel, MindView, Inc. Design by Interspire