Question about order of initialization

[Stefanos Kapa]

Hello everyone!
From the OCA study guide, I read the following statements:

"Fields and instance initializer blocks are run in the order in which they appear in the file."
as well as
"You can’t refer to a variable before it has been initialized"

After reading that part about order of initialization, I did some experiments, namely:

public class Test {

{
	name = "Bob";
}

String name;

}

Quite surprizingly, this class does compile.  The field name is declared only after the initialization block, so shouldn't that produce a compiler error?
Then I made the hypothesis, that the compiler moves all field declarations to the top (is hoisting a thing in Java??).
But even if the above happens, this doesn't explain why the following code fails to compile:

public class Test {

{
	name = "Bob";
        System.out.println(name);
}

String name;

}

Any ideas ?

[Jesse Silverman]

People seem to be somewhat split about what point is knowing too much about static and instance variable initialization, and what is knowing just enough.

Searching Google for:
"Read indirectly write only" state java

Yields 152 results, including:
https://srikarbandla.wordpress.com/2015/07/31/static-control-flow/

Chapter 12 of the JLS goes into rather a lot about these things...

At the moment, I am leaning towards "Make sure you know everything about initialization of instance members and static members that your chosen preparatory materials details."

If you fall short there, the choice of preparatory materials may be inadequate.

It might be easier to know "too much" about this, from the point of view of exam preparation in the face of "lots of different stuff to know".

[Paul Clapham]

Stefanos Kapa wrote:"Fields and instance initializer blocks are run in the order in which they appear in the file."

Notice the word "run" there. That refers to events which take place at run time. Don't confuse them with declarations, which are dealt with by the compiler at compile time.

That sounds simple but from your two examples it can be seen that it isn't all that simple. Obviously "System.out.println..." is an event which takes place at run time, there's no doubt about that. You might well believe that the assignment to variable "name" which appears in both of the examples belongs to the run time category, but since the compiler treats it differently it can be seen that it belongs to the compile time category.

So as Jesse said, it's complicated. Follow the advice he gave you.

[Stefanos Kapa]

Thanks for your insightful answers!

Indeed it is hard to determine from a student perspective what is too much, what enough and what not enough.  Java mock exams can get really tricky, so I prefer knowing too much than not enough.

Browsing through the JLS, I found something about this specific case:

8.3.3. Forward References During Field Initialization
Use of instance variables whose declarations appear textually after the use is sometimes restricted, even though these instance variables are in scope. Specifically, it is a compile-time error if all of the following are true:

The declaration of an instance variable in a class or interface C appears textually after a use of the instance variable;

The use is a simple name in either an instance variable initializer of C or an instance initializer of C;

The use is not on the left hand side of an assignment;

C is the innermost class or interface enclosing the use.

That doesn't really explain the reason, but at least there is a consistent set of rules for that case, I guess thats good enough for the certification.

[Jesse Silverman]

Welcome to the Ranch, by the way!

As I read the bit you put up, I feel myself saying "Yeah, that makes sense" and simultaneously realizing how much stuff within scope of both the exams and outside of it is more practical and important for daily effective use of Java that I could spend the same time on.

I zoom out and think how I remember it is 100 times as hard to draft a specification that handles everything correctly, including those insanely weird corner cases we all forget about all the time, then to have something 98% or 99% solid.

The specific rules about this may just be because it is very hard to unambiguously specify or code the compilations otherwise.

People who don't have experience with other standards documents often think it is hard to read, or gets really abstract in places....I think that it (using metonymy, I mean its authors) takes its responsibility as a living, breathing specification for a language that needs to be used by millions of people pretty seriously.  I find 80% of it readable, and when I see the other 20% I can only imagine that if I spent enough time thinking about the potential complications that are unlikely to happen but quite possible, and therefore, must be addressed correctly, I wouldn't be able to make it any simpler.

I referred to the primary preparatory materials, because I remembered both Hanumant Deshmukh and our Sybex authors both covered these issues thoroughly, yet tersely, in a way that would be more readable than the JLS.  I've also seen videos that covered it pretty well, tho I remember one taking a full hour to get thru it.