*
The moose likes Java in General and the fly likes The static safety Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "The static safety" Watch "The static safety" New topic
Author

The static safety

Erik Pragt
Ranch Hand

Joined: Sep 08, 2001
Posts: 125
Well, I took me some time formulate this question, so I hope I will be clear enough...
What I try to do is to create a simple validation class, called FieldCheck.

This code gets executed by some other piece of code (well, this is not really the code, but for simplicty, I created a 'working' example):


Okay, this works, and no problem here. But now my real question: will FieldCheck be garbage collected??
I hope not, because the (obvious) purpose of this construction was to create (compile) the Patterns only once.
But what will happen if the FieldCheck gets garbage collected, if ever. Those are actually my 2 questions:
1) Will it be garbage collected
2) What will happen if it gets garbage collected? (I mean, will the 'static' be called upon a new checkFirstName()?)
If I run into problem with this, is there maybe a different solution to my problem??
Thanks in advance for any replies. If I haven't made my post clear enough, please let me know so I can clear any unclear parts in the post.

Erik
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61769
    
  67

Since you never create an instance of the class, there's nothing to be garbage collected in the first place.
hth,
bear


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
The class of FieldCheck itself is an object (of class java.lang.Class). It is also subject to the rules of garbage collection.
A highly optimized JVM could gc the class object, and re-create it when necessary (i.e when refered again).
-GB.
Erik Pragt
Ranch Hand

Joined: Sep 08, 2001
Posts: 125
Bear: I think you are a little wrong here...
Gopi:If you are right, is there any way to prevent this, and is it necessary to have this prevented??
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
Originally posted by Gopi Balaji:

A highly optimized JVM could gc the class object, and re-create it when necessary (i.e when refered again).

This is an academic proposition. I dont know if any JVM actually does that.
JVM implementations are free to adopt their own policies/strategies of Garbage collection and Class loading/unloading. The JVM spec give them (quite a) wide leeway in this matter.

To be on the safe side, any static initialization should be idempotent. It might be a bad idea, say, to open a DB connection in a static block.
Are there any JVM experts out there who can add their insights to this matter?
-GB.
Erik Pragt
Ranch Hand

Joined: Sep 08, 2001
Posts: 125
Well, it doesn't matter if it gets recreated, as long as the

part gets called again...however, it would be nice if someone with a little more knowledge about the JVM could shine it's light on this...
Erik
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
From The JLS 12.7 Unloading of Classes and Interfaces

An implementation of the Java programming language may unload classes. A class or interface may be unloaded if and only if its defining class loader may be reclaimed by the garbage collector as discussed in �12.6. Classes and interfaces loaded by the bootstrap loader may not be unloaded.

As long as your class is being loaded by the bootstrap class loader and not a custom ClassLoader it will never be unloaded.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
Originally posted by Cindy Glass:
From The JLS 12.7 Unloading of Classes and Interfaces


As long as your class is being loaded by the bootstrap class loader and not a custom ClassLoader it will never be unloaded.

Thanks for pointing this out. This effectively nullifies my earlier observations.
A class is defined not only by its fully qualified name, but by also its defining class loader. In essence, the defining class loader holds a reference to the class object. So, if the reference is still alive, the class is not eligible for being GC-ed. Else, it is. The rules for GC still holds good.
But, a JVM, however optimized, cannot unload this class, when its defining class loader will still be alive.
-GB.
Erik Pragt
Ranch Hand

Joined: Sep 08, 2001
Posts: 125
Thanks,
all of you! Now I can go to bed with a safe feeling
Thanks, Erik
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
I found this relevant to our discussion -
http://developer.java.sun.com/developer/technicalArticles/Programming/singletons/
Search for "Singleton Classes Destroyed by Garbage Collection, then Reloaded", and also read the subsequent seciton.
I had always thought class objects could be GC-ed (hence my caveat about non-idempotent static blocks), and was jolted to read Cindy's reference.
But, thanks to Cindy, I have now upgraded my understanding of the GC mechanism from pre 1.2 to post 1.2.
-GB.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: The static safety