In Java, How to Know Whether a Class Has Already Been Loaded

In Java, is it possible to know whether a class has already been loaded?

(Thanks to Aleksi) This code:

public class TestLoaded {
public static void main(String[] args) throws Exception {
java.lang.reflect.Method m = ClassLoader.class.getDeclaredMethod("findLoadedClass", new Class[] { String.class });
m.setAccessible(true);
ClassLoader cl = ClassLoader.getSystemClassLoader();
Object test1 = m.invoke(cl, "TestLoaded$ClassToTest");
System.out.println(test1 != null);
ClassToTest.reportLoaded();
Object test2 = m.invoke(cl, "TestLoaded$ClassToTest");
System.out.println(test2 != null);
}
static class ClassToTest {
static {
System.out.println("Loading " + ClassToTest.class.getName());
}
static void reportLoaded() {
System.out.println("Loaded");
}
}
}

Produces:

false
Loading TestLoaded$ClassToTest
Loaded
true

Note that the example classes are not in a package. The full binary name is required.

An example of a binary name is "java.security.KeyStore$Builder$FileBuilder$1"

Is there any way to judge whether a class has been loaded into jvm?

OK, so I have not done this. But it seems that it would be possible via getAllLoadedClasses() in the Instrumentation API.

But then you would still need to start the JVM with your agent.

How to check whether a class is initialized?

You can use the ClassLoader.findLoadedClass() method. If it returns null, then the class isn't loaded. This way you don't load the class if it wasn't already loaded.


WARNING : This code doesn't really work here, in the system ClassLoader, findLoadedClass() is protected, you need to override it with your own ClassLoader.

Check the link below On the same topic to check if a class is loaded with the system ClassLoader

if(ClassLoader.getSystemClassLoader().findLoadedClass("java.lang.String") != null){
System.out.println("Yepee, String is loaded !");
}

Very good point from @irreputable :

"loaded" doesn't mean "initialized". initialization only happens at precise moments defined by JLS3 $12.4.1

And I quote :

A class or interface type T will be initialized immediately before the first occurrence of any one of the following:

  • T is a class and an instance of T is created.
  • T is a class and a static method declared by T is invoked.
  • A static field declared by T is assigned.
  • A static field declared by T is used and the field is not a constant variable (§4.12.4).
  • T is a top-level class, and an assert statement (§14.10) lexically nested within T is executed.

Invocation of certain reflective methods in class Class and in package java.lang.reflect also causes class or interface initialization. A class or interface will not be initialized under any other circumstance.


Resources :

  • Javadoc - ClassLoader.findLoadedClass()
  • Internals of Java Class Loading
  • JLS - §12.4.1 When Initialization Occurs

On the same topic :

  • In Java, is it possible to know whether a class has already been loaded?

When is a Java Class loaded?

There is no simple answer to this question. The specification leaves room for different implementation strategies and even within one implementation, it will depend on how the class is been used. Further, your question is more about “when can it fail” which depends on why it may fail, e.g. a class may be loaded at one point of time to verify its existence but initialized at a later time when it is actually first‑time used. At both points of time, the operation may fail causing a NoClassDefFoundError.

We may categorize referenced classes into three groups:

  • classes that must be resolved at linkage time (e.g. the superclass)
  • classes that must be loaded at verification time
  • classes whose loading can be deferred to it’s first actual use

In your case, BouncyCastleProvider must be loaded at verification time, rather than its first actual use, because you are passing the result of new BouncyCastleProvider() as argument to the method Security.insertProviderAt(…) and the verifier must check whether the class actually extends the Provider type which the method’s formal parameter mandates.

When verification will happen, is also implementation specific as at least the following possibilities are allowed:

  • eagerly traversing all referenced classes
  • on the loading of the containing class or its first use
  • on the containing method’s first use
  • right before executing the offending instruction

Oracle’s JVM prefers a method’s first use, read: verify it at the method entry, thus, moving the invocation into another method that won’t get executed, be it in another class or not, is sufficient in your case.

But to be compatible with other JVMs, moving it into another class is safer, but to comply to all possible JVMs, you need to even load this other class via Reflection to avoid a direct reference that can be traversed by an eager implementation (or instantiate BouncyCastleProvider reflectively via Class.forName("… .BouncyCastleProvider").newInstance() in the first place).



Related Topics



Leave a reply



Submit