CLASSES(4)

CLASSES(4)

Initialization of fields: a field declaration with a variable initialiser has the semantics of an assignment to the declared variable and,
- if the declaration is for a class variable (i.e not a static field), then the variable initialiser is evaluated and exactly a single-time assignment performed, when the class is initialized. If the evaluation of a variable initialiser for a static field of a named class(or an interface) can complete abruptly with a checked exception, then this is a compile-time error.
- If the declaration is for an instance variable, (i.e a field that is not static,), then the variable initialiser is evaluated and the assignment performed each time an instance of the class is created. If an instance variable initialiser of a named class can throw a checked exception, then there is a compile time error, otherwise that exception or one of its supertypes is explicitly declared in the throws clause of each constructor of its class and the class has at least one explicitly declared constructor.
An instance variable initialiser in an anonymous class can throw any exception.

Initialization of class variables:
a. any reference to the simple name of an instance variable will result in an error in a class variable initialization expression..
b. use of the keyword this or super in a class variable initialization expression will result in an error.
c. Class variables declared final and initialized with compile time constants will always be initialized first, whether in classes or interfaces.
d. A restriction is placed on using a class variable before its textual declaration, whether or not the class variable is in scope.

Initialization of instance variables:
a. initialization expressions for instance variables may refer to the simple names of class variables.
b. The expression may use the keyword this and super .
c. Restrictions exist on the use of an instance variable before its textual declaration.

Restrictions on the use of fields during initialization:
The declaration of a member of a class needs to appear textually before usage only if the member is an instance (respectively static) field of a class that directly encloses it and the following conditions hold:
a. the usage occurs in an instance variable initialiser(respectively static) of the enclosing class or in an instance initialiser (respectively static) of the enclosing class.
b. The usage is not on the leftmost side of an assignment
c. The usage is via a simple name
d. This class is the innermost class enclosing the usage.

Note: take usage to refer to the main method’s class and you’ll understand why following the rule that you should try to textually declare before usage can really save you some grief. If usage was within same class as instance variable, then static modifiers for the variable would be a must requirement.

METHOD DECLARATIONS:
A method declares executable code that can be invoked, passing a fixed number of values as arguments.

The formal notation for method declaration is: MethodHeader MethodBody

We’ll treat MethodHeader first.

The MethodHeader consists of :
MethodModifiersopt TypeParametersopt ResultType MethodDeclarator Throwsopt

The MethodModifiers, TypeParameters and Throws sections will be discussed shortly. The ResultType signifies the type of value that the method returns and this could be void, that means, it doesn’t return any value, or a recognized type.

The MethodDeclarator has the following notation: identifier (FormalParameterListopt)
The identifier is used in a name to refer to a method.

Try to avoid using same names for methods, classes, fields, member classes or interfaces even if they do not result in compile time errors.

Using two methods with the same signatures (name, number of parameters and types of parameters), will result in a compile time error.

Formal Parameters: the formal parameters of a method or constructor, if any, are specified by a list of comma-separated parameter specifiers.

The parameter specifiers have the notation:
VariableModifiers Type VariableDeclaratorId

Taking them one by one, the VariableModifiers are one or both of final and an annotation. The type specifies the allowed type of the arguments for the method and the VariableDeclaratorId could be an identifier or an array of the specified type. The specification here is for a fixed arity parameter or a case where the number of parameters that are allowed are known, finite and specified as to number. Where the number of allowed formal parameters are not specified, the method is said to have a variable arity parameter of the form methodname(Type… id ) where id is either a simple name or an array of the specified type.
A compile time error occurs if two methods or constructors possess the same formal parameters when they have the same identifier or names.

If an annotation a on a formal parameter corresponds to an annotation type T, and T has a (meta-)annotation, m such that m corresponds to annotation.Target, then m must have an element whose value is element.ElementType.PARAMETER, otherwise a compile time error is issued.

When the parameter of a method is declared final, it is a compile time error to attempt to assign the parameter within the body of the method.

Note that on invocation of a method or constructor, the arguments passed to the method initialize newly created parameter variables each of the Type mentioned in the formal parameter of the method and passed as their simple names before usage in the method body. Note that the identifier mentioned as a parameter in the method declaration may be used to refer to the formal parameter in the body of the method.

Never declare parameter names in local variables of a method or as exception parameters of catch clauses in a try statement of the method or parameter. However, if a method contains a nested class declaration, the parameters of the method may be shadowed inside the nested class. Note though that the nested class should be a local class or an anonymous class.

Never use a qualified name to refer to a formal parameter, only simple names.

If a parameter contains a parameter of type float the value of the float should be in the float value set, and if in the extended-exponent value set this should map well to the float value set otherwise a compile time error results. Same goes for parameters of type double.

But where an actual argument expression corresponding to a parameter variable is not FP-strict, during evaluation of the actual argument expression, intermediate values from the extended-exponent-value set can be used, but prior to being passed to the parameter variable par value, these values have to be mapped to the corresponding value set by method invocation conversion.

An example that illustrates other features pertaining this topic:

package examples;

public class MyMethod {
String terms;

//this method returns no value and has fixed arity parameters,
//which are 1 in number.
void simpleMethod(final String builder){
//we'll refer to the arguments passed with the name
//builder and because of final, it can not be assigned
System.out.println("What was passed was a String,
"+builder);
}

//this method has variable arity parameters, which is considered
//to define a String[]. so am querying the length here.
void variablearity(String... somestrings){
System.out.println(somestrings.length+" parameters were
passed.");
}

//this method has no parameters, empty pair therefore in
//parentheses
String noparam(){
return terms;
}
}

class Loader {

public static void main(String[] args) {
MyMethod thema = new MyMethod();

//new variable initiallized on invocation of simpleMethod
//with type String
thema.simpleMethod("foobar");

//on invocations of a variable arity method, you can define
//how much parameters to pass yourself
thema.variablearity("oh boy", "terrific!", "humdrum");
System.out.print("later ");
thema.variablearity("naughty", "ohlolo", "tellme",
"finale");
}
}

(to be continued)