The static safety

[Erik Pragt]

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.

public class FieldCheck
{
  public static String REGEX_FIRST_NAME = "[a-zA-Z]";
  private static Pattern firstNamePattern;
  static
  {
    firstNamePattern = Pattern.compile(FieldCheck.REGEX_FIRST_NAME);
  }
  public static boolean checkFirstName(String input)
  {
    Matcher m = firstNamePattern.matcher(input);
    return m.matches();
  }
}

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):

if(FieldCheck.checkFirstName(firstName))
  UserAccount.setFirstName(firstName);

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]

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

[Gopi Balaji]

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]

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]

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]

Well, it doesn't matter if it gets recreated, as long as the

static
{
  ...
}

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]

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.

[Gopi Balaji]

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]

Thanks,
all of you! Now I can go to bed with a safe feeling
Thanks, Erik

[Gopi Balaji]

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.