initialisation : Java Glossary
home I words local find no local find frame, full screen Google search web for topic jump to footer translate with Babelfish by Roedy Green ©1996-2008 Canadian Mind Products
Go to : punctuation 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (all)
initialisation
Java automatically initialises all non-local variables with a default value, i.e. 0 or null, even chars. However Java does not automatically initialise local variables, though it will initialise any arrays or objects newly created to be stored in local variables. The Java compiler is clever. If you forget to initialise when it is required, it will tell you at compile time. You never need to worry about inadvertently accessing uninitialised variables. Java always protects you from your folly. When you create an array of objects, Java automatically initialises all the slots to null, for both singly and doubly dimensioned arrays e.g. String [ ] or String [ ] [ ]. It does not create a new object for each slot.

There are three kinds of variable, local, instance (one member per object), and static (one per class). When you first use a class, its class variables are initialised. When you first use a new SomeConstructor, the object’s instance variables are initialised. There is no automatic initialisation for local variables. Usually you initialise them inline. Here is the order in which the six types of initialisation are applied. The types of initialisation near the top of the table are applied first.

Various Ways To Initialise the Three Kinds of variables
Type of Initialisation Local Instance Static Notes
automatic null or zero No code needed. char = 0, not ' '; reference = null, int = 0;
inline known finals
e.g. final int MAX_WEIGHT = 1000;
If the compiler can figure out the value of the expression at compile time, it gets done first ahead of the other inline initialisations. If it can’t, then it is treated as an ordinary inline initialisation, even though it is final.
inline
e.g. int a = 1;
Interleaved in textual order with static {} or instance {}.
static init block
e.g. static {a = 1;}
* Interleaved in textual order with inline initialisations. There is a separate static init for a nested class that is not run until a nested class is first instantiated.
init block
e.g. {a = 1;}
* Interleaved in textual order with inline initialisations.
constructor
e.g. a = 1;
constructor to see how constructors are chained to do a series of initialisations
assignment in a method
e.g. a = 1;
procedural code, not really initialisation.
* local variables initialised in an init block or static init block must be declared in that block, and have scope confined to that block.

According the

, after the zero initialisations, the class variable initializers and static initializers of the class, or the field initializers of the interface, are executed in textual order, as though they were a single block, except that final class variables and fields of interfaces whose values are compile-time constants are initialized first. In other words static final constants known at compile time are logically done first. They are done very first, at compile time and by the time you load a class they are effectively literals. There are no actual static final variable slots that be initialised.

If you decompile you code, you will see a generated method called <clinit> that handles the static initialisation.

Beware of depending on inline initialisations of member or class variables being done in the order the variables are listed because various beautifier tools such as VAJ or Eclipse may reorder them. When the value of one variable depends on another, put the dependent initialisations in an init or static init block, where you have explicit control of the ordering, rather than using initialisation assignment statements. The compiler is not smart like a spreadsheet to figure out the dependencies and calculate them in natural order. It just starts and the top and works down doing the assignment initialisations and block initialisations in strict top down order.

The constructor must call the constructor of the superclass as the very first thing it does. If you leave out this code, the compiler inserts it for you. This means when you invoke a constructor, first the base fields are initialised, then the subclass. You are effectively invoking a daisy chain of constructors of the ancestor classes when you invoke a constructor.

There are three quirky consequences of the way Java does initialisation:

  1. You can safely do forward references to compile time constants in your initialisation code.
  2. You can define the value for a static final in a static init block that appears before the declaration.
  3. You many not do a forward reference in your initialisation code to a constant whose value is not known at compile time.

static final init Catch-22

There is a Catch-22 if you invoke code that could trigger exceptions in your static constant initialisation.
The Catch-22 is if you don’t initialise in the catch block, the compiler complains the var WEBSITEURL might never be initialised, but it you do initialise in the catch block, it complains you may be initialising twice. Further, you can’t simply wrap the static final declaration in a try block.

Here is a way to bypass the problem:

A variant would be to write a method to provide the initial value that handled the exception to disguise the ugliness.

CMP_homejump to top
CMP logo
feedback Please email your feedback for publication, errors, omissions, broken/redirected link reports
and suggestions to improve this page to Roedy Green : feedback email
made with CSS
HTML Checked!
ICRA ratings logo
mindprod.com IP:[65.110.21.43]
Your face IP:[38.103.63.17] The information on this page is for non-military use only.
You are visitor number 18,394. Military use includes use by defence contractors.
You can get a fresh copy of this page from: or possibly from your local J: drive (Java virtual drive/Mindprod website mirror)
http://mindprod.com/jgloss/initialisation.html J:\mindprod\jgloss\initialisation.html