"Small" Program Challenge.

[javax.swing.JSnarker]

Between loading and initialization theres still verification, isn't it?

Verification is a part of loading, rather than coming after it.

 

[javax.swing.JSnarker]

I'm curious: How do you want to verify something that you haven't loaded
yet?

I don't. Neither do I want a loaded class hanging around unverified
afterward, though. So the two belong back-to-back. Essentially,
obtaining the byte code from wherever into main memory is step 1 of
loading, and verifying it is step 2.

 

[Lew]

How I would expect this to work in reality.

1. Load class
2. get a reference to the static method "void main(String[])"
3. Attempt to execute that reference
3.1 Causes class initialization before execution.
3.2 actual execution occurs.

That has a problem, though, in that class initialization will happen on
every method call, resulting in multiple initializations, if it's part

That's not what happens.

of "attempt to execute the reference" rather than (as the spec says)
something the JVM does immediately *before* the first such attempt (or
other action that requires an initialized class for the action to begin).

As the spec says, it happens upon the first attempt to execute a static method
(if the class has not already been initialized).

I suppose you could change 3.1 to "see if the class is initialized, and
if not, initialize it", but even that would add to *every method call*

That is what the spec says to do. As previously linked.

the overhead of a test-and-branch, and would still be dodgy at best on
spec-adherence grounds.

No, it does what it does and adheres to the spec.

See the previously linked references for the details.

 

[javax.swing.JSnarker]

How I would expect this to work in reality.

1. Load class
2. get a reference to the static method "void main(String[])"
3. Attempt to execute that reference
3.1 Causes class initialization before execution.
3.2 actual execution occurs.

That has a problem, though, in that class initialization will happen on
every method call, resulting in multiple initializations, if it's part

That's not what happens.

I'm not finished. Class initialization will happen on every method call,
resulting in multiple initializations, *if it's part* of "attempt to
execute the reference" rather than (as the spec says) something the JVM
does immediately *before* the first such attempt (or other action that
requires an initialized class for the action to begin).

As the spec says, it happens upon the first attempt to execute a static method
(if the class has not already been initialized).

No, the spec does not say "upon" it says "immediately before".

That is what the spec says to do. As previously linked.


No, it does what it does and adheres to the spec.

No, what the spec says to do is to implement a statically-compiled call
this way:

Class is loaded and initialized by statically-compiled code.
Method invocation is simply a bare invokestatic instruction

And a reflective/otherwise non-static call this way:

Check if class is loaded and if not load and verify it.
Check if class is initialized and if not initialize it.
Check if method exists and if not throw an exception, otherwise invoke it.

And this is apparently what earlier versions did.

Surely you aren't suggesting there's a whole raft of if
(class_is_loaded), if (class_is_initialized), etc. tests before every
method call in Java 7? Because that would make method calls much slower
than before, unless you've got some cleverness in place to remove those
tests from the code once the class is loaded. In other words, something
more like expanding each call into

load_and_initialize_if_needed(X.class);
invokestatic...

where load_and_initialize_if_needed(X.class) strips out all instances of
load_and_initialize_if_needed(X.class) from all loaded bytecode as part
of its own behavior. But that would have all kinds of difficulties of
its own. At least the JIT might be able to skip over it if X is already
loaded and an instance is in code it's JITting.