Static and Instantiation

[Jason Cavett]

If I make a static class (AKA - everything in a class is static), does
that mean this class is loaded into memory as soon as the JVM starts
(assuming the class is being used somewhere within the application),
or is it lazily instantiated and not loaded into memory until it
actually needs to be used?

I searched around, but couldn't find the information. Thanks.

 

[Joshua Cranmer]

If I make a static class (AKA - everything in a class is static), does
that mean this class is loaded into memory as soon as the JVM starts
(assuming the class is being used somewhere within the application),
or is it lazily instantiated and not loaded into memory until it
actually needs to be used?

I searched around, but couldn't find the information. Thanks.

Class files are loaded on demand.

 

[Lew]

Class files are loaded on demand.

And initialized somewhat later.

OP: Check out the JLS.
<http://java.sun.com/docs/books/jls/third_edition/html/
execution.html#12.2.>
<http://java.sun.com/docs/books/jls/third_edition/html/
execution.html#12.4>

One of the more interesting consequences of these rules is that you
can refer to the 'class' literal (as in 'SomeClass.class') without
initializing the class. This has consequence for reflection.

 

[Mark Space]

If I make a static class (AKA - everything in a class is static), does
that mean this class is loaded into memory as soon as the JVM starts
(assuming the class is being used somewhere within the application),
or is it lazily instantiated and not loaded into memory until it
actually needs to be used?

I searched around, but couldn't find the information. Thanks.

Probably the lazy instantiated one, but if it's critical you may not
want to count on it.

The default JVM loader does not load or initialize classes until needed,
but if your class goes through a JIT optimizer, your application just
might get all initialized and loaded right at start up, depending on how
the JIT compiler "sees" your code.

The best way to do this would probably be to count on lazy instantiation
(it'll work 99% of the time) but leave enough instrumentation in the
code that you can tell if it ever doesn't happen. In other words,
collect data from the running program. If you see performance drop and
the static class is the issue, you can tackle the problem then.

I'd log the static init procedure, and log just before you use it. So,
if you see the class getting initialized, but never see the "use" log
message, something happened to the lazy init feature.

 

[Jason Cavett]

Probably the lazy instantiated one, but if it's critical you may not
want to count on it.

The default JVM loader does not load or initialize classes until needed,
but if your class goes through a JIT optimizer, your application just
might get all initialized and loaded right at start up, depending on how
the JIT compiler "sees" your code.

The best way to do this would probably be to count on lazy instantiation
(it'll work 99% of the time) but leave enough instrumentation in the
code that you can tell if it ever doesn't happen.  In other words,
collect data from the running program.  If you see performance drop and
the static class is the issue, you can tackle the problem then.

I'd log the static init procedure, and log just before you use it.  So,
if you see the class getting initialized, but never see the "use" log
message, something happened to the lazy init feature.

Alright. Actually, the laziness of instantiation isn't the problem.
It's actually the reverse. I don't want everything loaded.

The reason for this is I'm developing a Java library for some other
applications, and it is rather large. I wanted to make sure that the
few classes that I made static wouldn't get loaded just by the sheer
fact that someone was using another component in the library that had
nothing to do with that class.

Intuition told me that it wouldn't make sense to load all the static
"stuff" up front (although, good point about the JIT compilers), but I
wanted to check to make sure.

Thanks for the response.