Java ClassLoader and dependency resolution

Question

Can anyone clarify that the role of ClassLoader is not only in loading a separate class, but also in its dependencies? And if so, what exactly does the whole process entail? I am looking for implementation details, if at all possible.

For example, at some point, the bytes will need to be read from somewhere (network or file system location), and the file system locations should be calculated based on the canonical class name and foreknowledge of the class paths available by the JVM, as an individual ClassLoader user tries to find the file by potentially multiple classpaths? Where does he get this information from? Also, at what point are the bytes of class files checked and its dependencies checked for availability?

We will consider in more detail :)

Answer 1

ClassLoading is a very complicated question. The Security Model ClassLoader and Java are inextricably linked. Essentially, the JVM loads classes on demand. When there is a hierarchy of class loaders, the JVM tries to resolve the class as far down the chain as possible. In short, if the class is defined in the bootloader and in the classloader defined by the application, it will always use the version in the bootloader.

Inside a class loader such as URLClassLoader, the search order is the order in which you told it to look. Essentially, the array of URLs you told him had classes will search from the first record to the last.

When the class that you defined refers to another class, that class is also resolved using the same algorithm. But here's the catch: he only decides it as to where he was found. Let's take a scenario where the SomeCoolThing class is in the bootloader of the classes, but depends on SomeLameThing, which is in the application-specific classloader. The process will look like this:

App-ClassLoader: resolveClass("SomeCoolThing") parent->resolveClass("SomeCoolThing") Boot-ClassLoader (the ultimate parent): resolveClass("SomeCoolThing") SomeCoolThing needs SomeLameThing resolveClass("SomeLameThing") // Can't find SomeLameThing!!!! 

Although SomeLameThing is located in the classloader where you requested SomeCoolThing, SomeCoolThing was enabled in another classloader. This other classloader is unaware of the classloader and is trying to solve it on its own.

I had a long-standing book that covered Java ClassLoaders at a very good depth, and I recommend it. This is Java Security from O'Reilly Media . It will answer every question that you never wanted to know, but you still need to deal with ClassLoaders and how they work.

Answer 2

I can answer some of your questions:

how does an individual ClassLoader work to find a file by potentially several class classes?

If you mean that different class loaders have different classes, then each class loader accepts the properties (for example, classpath) of the parent class loader. All things equal to each class loader have the same class path as any other (I suppose I'm not sure the JVM is doing something weird inside). Thus, MyClass.class is the same for the class loader and all class loaders. If you have several MyClass.class classes defined on the same class path, the JVM takes the first. Previously, I created my own class loader and added my own path to the existing class path for loading classes at runtime that were not in the class path at startup.

Get into nuts and bolts. I am sure that there is a specification that describes this, or you can download the JVM code (assembly code / C / C ++) and go, although I had it for this and "it is not very."

Of course, “they” change the classpath material in 1.7, so I'm not sure how this will work ...

Hope that helps a bit ...