Let's start by taking a look at variables in Java.
Because variables are used so frequently, they need to be stored where they can be quickly accessed. The stack provides this place. Each local variable, whether it is a primitive data type or a reference variable, is stored on the stack. When you use a variable's name, the computer quickly locates that variable in memory and retrieves its value.
Physically, the stack is nothing more than a block of memory. The system handles all the details of managing its size so you don't have to worry about it.
When you call a method, that method is given a portion of memory at the top of the stack to store its local variables and parameters. Because each method uses its own portion of the stack, one method cannot modify the local variables of another methods.
When a method returns (or finishes running), the portion of memory on top of the stack used by that method is freed by the system. In other words, that method's variables no longer exist in memory. The following Stack N' Heap demonstrates this:
Code
{
int myVar = 5; dosomething ( ); System.out.println( myVar ); } public void dosomething ( ) { int myVar = 18; System.out.println( myVar ); } |
Stack
|
Heap
|
Temporary
|
Because methods in different classes do not share memory, the only way methods can share information is via parameters and return values. A calling method can send information to the called method by giving values to that method's parameters. A called method can return information to the calling method using a return value. The following Stack N' Heap demonstrates the use of return values.
Code
{
int myVar = 5; myVar = dosomething2 ( myVar ); System.out.println( myVar ); } public int dosomething2 ( int temp ) { return ( temp + 15 ); } |
Stack
|
Heap
|
Temporary
|
Variables can also refer to objects. The stack space for the variable only needs to contain the reference to the object. The objects themselves are stored on the heap, another area of memory that is much larger than the stack.. The system cannot find an object once it is stored on the heap unless it knows its address; object addresses are stored in reference variables.
Objects that cannot be accessed through a reference variable are useless. However, they may still take up may space in the heap. To reclaim this space, a procedure called garbage collection is periodicly run by the Java system. This process scans the stack and heap to find objects that can be removed. The system handles this automatically; you needn't worry about it.
As mentioned above, a calling method can send information to a called method
by giving values to that method's parameters. A method's
parameters are declared in the parenthesis immediately following the
method's name. The syntax for declaring a parameter is very simple,
it is identical to declaring a variable. For instance:
the method header
public void dosomething (int param1, String param2)
begins a method named
dosomething
that has two parameters:
an integer named param1
and a
String
reference variable named param2
.
In order to call this method,
you must provide an initial value for each of these parameters, such as
dosomething(5, "This is a test");
.
The
values passed to the called method become the initial
values of the called method's parameters.
When you call a method you must specify the initial values of its parameters; these values can be changed as the method runs. Using the assignment operator, you can change the value stored in a parameter, but this will have no effect on the variable stored in the calling method:
Code
{
int myVar = 5; dosomething3 ( myVar ); } public void dosomething3 ( int temp ) { temp = temp + 15; } |
Stack
|
Heap
|
Temporary
|
Remember that reference variables store addresses. When a parameter is a reference variable, it must be given an object's address as its initial value. You can use the assignment operator to change the address stored in a reference parameter; however, this does not change any variables used by the calling method. Now you can use the address stored in the reference parameter to change the instance variables of the object to which it refers. These changes will exist after the method stops running. The following Stack N' Heap illustrates this:
Download References.zip, a ZIP file containing a NetBeans project named
References and unZIP this project
into your csci/201 directory.
Try to make your Projects panel look
something like the following picture before continuing.
The file DeuxTons.java defines a simple class
that represents an object with two colors; a "top" color and
a "bottom" color.
The file References.java
contains a main
method that instantiates two DeuxTons
objects.
The main
method makes eight calls
of the static Click
method of the class
TwoToneDisplay
, four times for each
DeuxTons
object.
The Click
method takes a "picture" of a
DeuxTons
object. It displays the picture
inside a small frame with labels similar to
3'th picture. That label indicates the
picture's number within the "roll".
The picture contains two circles. The top circle
has the "top" color of the DeuxTons
object.
The bottom circle has the "bottom" circle.
Between the two colored circles, you will see a line proclaiming
something like I'm 342589. That number is an
object ID, obtained by calling the hashCode
method.
This ID is guaranteed to be unique for every Java run-time object.
Go ahead and run Reference
's main
method. You should see the eight Click
's.
The colors will differ from this example, because new colors
are randomly chosen on each run.
The eight pictures will probably fill your screen.
If you terminate any picture, all will disappear.
Within the main
method of References
there are comments that
describe modifications you are to make to
DeuxTons
objects or to references to
DeuxTons
objects during this lab.
After each modification, main
calls
the Click
method twice to display the result of
your modification.
Your job is to add code to the main
method
so that it performs the modifications described in the comments in
References.java.
There are three
modifications that you that you must make.
Some of these modifications will require that you call
the getTop
, getBottom
,
setTop
, and setBottom
methods
of DeuxTons
.
You should look at the code within DeuxTons.java to
learn more about these methods; however,
the only file you are allowed to modify to complete this lab is
References.java.
The first two pictures are Click
's of
ColorPair1
and ColorPair2
immediately after their creation.
We have two local variables,
ColorPair1
and ColorPair2
,
within your main
method that point to
different DeuxTons
objects.
Each of the two DeuxTons
objects point have
reference variables that point to different Java Color
objects.
Your first task is to swap the two objects referenced by
ColorPair1
and ColorPair2
.
After that swap, the order in which the
DeuxTons
objects are displayed will be referenced.
You can also check the hashCode
displayed after
I'm to make sure you have
correctly switched the two.
Now you are going to swap the top colors of each DeuxTons
object. Note that you do not change
the object references of ColorPair1
and ColorPair2
.
You change that state of their objects!
Your final modification is to swap the bottom and top colors
of each DeuxTons
object.
A correctly working solution should resemble the following
set of eight pictures.
Show your lab instructor your complete code with all modifications. The ultimate display should resemble the picure shown after. Pay careful attention to the object ID's displayed in the middle of each picture.
The instructor will probably look at your code to verify that DeuxTons.java has not been modified.