1. CALL BY VALUE PARAMETER PASSING

We have seem that methods may have formal parameters associated with them. These formal parameters get assigned copies of the actual parameters when the method is called. The parameter then acts as a local variable within the called method. Any changes made to the value of this variable last only for the lifetime of the method and do not affect the original value. This is called call by value parameter passing.

The effects of call by value parameter passing are illustrated in the short piece of application code given in Table 1. The output from this code is as follows:

localDataItem1 = 1
formalParameter = 1
formalParameter = 3
localDataItem1 = 1     

Thus, referring to the code presented in Table 1, we have a local data item localdataItem which is passed as the actual parameter to the doit method where it is output, changed and output again. However, this change does not effect the value of the data item in the calling method. This is because we are working with a copy of the data item and not the data item itself.

The disadvantage of the call by value parameter passing mechanism is that a copy is always made of the actual parameter to obtain the formal parameter.

2. CALL BY REFERENCE VALUE PARAMETER PASSING

There are in fact two techniques used in Java for passing arguments. The second is called call by reference value and is used in relation to data items which are stored by reference such as an object or an array. Given an object identifier this "points" to a start address in memory where all the attributes and methods for that object are stored. Similarly given an array identifier this "points" to a start address in memory where all the elements of the array are stored. Thus if we wish to pass an array or object to a method we pass the identifier for that object which in fact is a reference to a start address and not the object itself. As a result any changes made to the values associated with the object/array will be carried out on the actual object and not a copy as in call by value.

This is illustrated by the code presented in Table 2 which will produce the following output:

localDataItem2 = {1,2}
formalParameter2 = {1,2}
formalParameter2 = {3,4}
localDataItem2 = {3,4}     

Note that the changes made here to the formal parameter are permanent. Programmers should be aware of this effect as it can lead to accidental changing of values associated with data items. The advantage offered by call by reference is that no copy is made of the data item, this gives significant efficiency advantages when dealing with large arrays or objects that have many attributes and methods associated with them.

Some more parameter passing examples are available using object references as arguments.

3. COMMAND LINE ARGUMENTS

In all the examples studied so far we have included a formal parameter in our main method:

main(String[] args)

and so far we have accepted this as just something that we have to do to make our programs work. From our knowledge of arrays we can now see that this is an array of instances of the class Strings called args. We can pass a value to this argument (an actual parameter) from the keyboard when invoking a program. For example earlier on we wrote a "Hello World" program that allowed the user to input their name which was then echoed to the screen together with the phrase "Congratulations on writing your first Java program which features some input!". A revised version of this program is presented in Table 3.

We can invoke this program and pass an argument to it as follows:

java HelloWorld3 "Frans Coenen"   

The result will be:

Hello Frans Coenen - Congratulations on 
writing a more sophisticated Java 
program that involves command line 
arguments! 

The value Frans Coenen is called a command line argument. We can have as many of these as we like. For example we might revise our program so that the output statement reads:

System.out.print("\nHello " + args[0] + 
        args[1] + args [2]);

and then pass in three arguments:

java HelloWorld3 "Dr." "Frans" "Coenen"

Let us consider another example. The code presented in Table 4 takes any number of command line integer arguments, adds them up and returns the total. There is however a "snag" as command line arguments are always strings. We must therefore convert each input string into an integer. We can do this using the appropriate "parse" method in the appropriate wrapper class, the parseInt method found in the Integer wrapper class in this case.

Once compiled we can invoke the application class presented in table 4 as follows:

$ java AddUpApp 1 23 456 789 245 678 
0 34        

from which we would expect the reply:

Total = 2226    

4. SCOPE RULES AND LIFETIME OF IDENTIFIERS

Scope rules govern the lifetime and visibility of identifiers, i.e. the parts of a program where they can be used. The term visibility describes the parts of a programme where a data item my be used. The term lifetime describes the period of time during a programmes execution when a data item exists in the computer's primary storage. Visibility and lifetime are not necessarily the same thing. In Java there are two types of scope:

	Class scope
	Block scope

Note that to use the code given in Table 5 we need an applications program of the form given in Table 6). The output would be as follows:

$ java ScopeRuleExampleApp
Total = 6, Average = 1.5

The exception to the above is where a field is overiden in a method contained within the class, i.e. where a local data item with the same name as a field is declared in a method. In this case the field is said to be occluded throughout the lifetime of the local data item, i.e. the field continues to exists but is temporerily not vissible.