views:

45

answers:

2

Is there a way to check if all boot (core) java classes (belonging to the Java Runtime Environment) have been loaded/initialized for use in Java?

I need to check this in a rare situation where I have have access to the JRE but not to the actual application, so I cannot simply wait for the main application to run and execute from that point on.

+1  A: 

The JVM will load classes on an "as-needed" basis, so there's no one point at which "all" of the classes on the bootstrap classpath will have been loaded.

That said, from 1.5 and onward, the Sun JVMs use "class data sharing" to pre-load a specific set of classes. I don't know which classes get loaded, but would suspect it's limited to those in the java.lang package.

If you simply want to keep track of when classes get loaded, use the -verbose:class command-line option when starting the JVM.

Anon
The list of files is in `lib\classlist`.
Tom Hawtin - tackline
This is only partly true. For example, if I call a new FileWriter in the constructor of the Object class, it will crash because the FileWriter class cannot been instantiated since there is no Object class yet. I am in a compareable situation, so this won't work for me. Unfortunately I do not have control of starting the JVM, there is no command line either.
Tom
@Tom - I think you need to edit your question and better describe what you're trying to do. Your example with Object and FileWriter doesn't make sense, because the Object class will indeed have been loaded and initialized before its constructor can be called. Perhaps you have a situation where a *static initializer* references a subclass? I believe that's the only case where you can get a circular dependency in class *initialization* (and I've seen it happen a lot with poorly-designed singletons).
Anon
I'm simply calling a new Filewriter in the constructor of the Object class of the JRE, it will crash. However, if I add a counter counting all loaded objects and call a new FileWriter when 2000 objects have been loaded, it does work within this constructor. This is because critical elements for a proper execution of the JRE have not been initialized yet.
Tom
A: 

having read your comments (and accidentally deleted my cookie), all I can say is that JVMTI is pretty much guaranteed to be a much better choice for whatever it is that you're trying to do.

But if you're hell-bent on modifying a JRE class, why not simply add a static boolean variable that will get set during FileWriter initialization?

Anon
Because the FileWriter was merely an example. I can't set such boolean in every class. Any other suggestions?
Tom
@Tom - If you would care to describe exactly what you're trying to accomplish, then perhaps someone can give you a better option. And it probably won't include modifying the built-in JRE classes.
Anon
I simply need to access all classes, their instances, methods and variables of any application using a certain JRE without having access to the source of the application and the ability to add new logic to an application. In case you are wondering, this is for personal non-distribution use only.
Tom