Class loading and the new keyword.

[chrislewis]

I've done some brief searching through the JLS for information on how
exaclty new works - specifically, how the class supplied as an
argument is located (what class loader is used). I haven't found
anything yet, but in my readings I've come to assume that new must use
the class loader of the enclosing class. So if in my application's
main() method I call new MyClass(), the classloader that loaded the
class containing main() (the application class loader) is used to
resolve the class. Is this correct?
Further, I'm looking in to creating a pluggable architecture for my
app and will probably need at least a simple custom class loader.
Let's say I created JarClassLoader and use it within a class loaded by
the AppClassLoader. When I load classes using the JarClassLoader
(assuming that AppClassLoader is the parent of JarClassLoader),
classes loaded via JarClassLoader can have access to those loaded by
AppClassLoader (because its the parent), but the reverse is not true
(classed loaded via JarClassLoader are not available to the rest of
the app loaded by AppClassLoader). Is this correct? If not could
someone fill in the holes?

much appreciated

 

[Karl Uppiano]

I've done some brief searching through the JLS for information on how
exaclty new works - specifically, how the class supplied as an
argument is located (what class loader is used). I haven't found
anything yet, but in my readings I've come to assume that new must use
the class loader of the enclosing class. So if in my application's
main() method I call new MyClass(), the classloader that loaded the
class containing main() (the application class loader) is used to
resolve the class. Is this correct?
Further, I'm looking in to creating a pluggable architecture for my
app and will probably need at least a simple custom class loader.
Let's say I created JarClassLoader and use it within a class loaded by
the AppClassLoader. When I load classes using the JarClassLoader
(assuming that AppClassLoader is the parent of JarClassLoader),
classes loaded via JarClassLoader can have access to those loaded by
AppClassLoader (because its the parent), but the reverse is not true
(classed loaded via JarClassLoader are not available to the rest of
the app loaded by AppClassLoader). Is this correct? If not could
someone fill in the holes?

The behavior is entirely up to the class loader. In fact, the entire concept
of a "classpath" is simply an implementation feature of the default class
loader. I think your best bet will be to study the class loader class
hierarchy and see what they all do. If you need some custom behavior, you
can extend one of them, and link it into the chain.

In the few times I truly needed my own class loader, I extended
URLClassLoader, which will also load files (despite, or perhaps hence, it's
name).

See also:
http://www.panix.com/~mito/articles/articles/classloader/j-classloader-ltr.pdf

 

[chrislewis]

Karl,

I read through the pdf and while helpful it didn't really touch on my
specific misunderstandings. Particularly, where/how the runtime finds
classes requested via new, and then if classes loaded by a child class
loader are at all available to classes loaded by the parent. I dont
think that part is true, but I'm seeking confirmation.

thanks again,
chris

 

[Karl Uppiano]

Karl,

I read through the pdf and while helpful it didn't really touch on my
specific misunderstandings. Particularly, where/how the runtime finds
classes requested via new, and then if classes loaded by a child class
loader are at all available to classes loaded by the parent. I dont
think that part is true, but I'm seeking confirmation.

The PDF touches on it, but I was looking through more documentation. The
post 1.2 class loaders use "reverse" delegation to parent class loaders, so
if you say "new String", the default class loader is called first, and finds
String. If you say "new Widget", the default class loader probably won't
find that unless you added it to the classpath. So child class loaders will
be called in turn, until some class loader has it, or can load it, or a
ClassNotFound exception is thrown if the chain of class loaders is
exhausted.

I think this article describes 1.2 ClassLoader delegation better:
http://www.javaworld.com/javaworld/jw-03-2000/jw-03-classload.html

 

[Roedy Green]

I've done some brief searching through the JLS for information on how
exaclty new works

new is a JVM op code. You might find the lawyerly stuff on how it
works in the JVM spec.

See http://mindprod.com/jgloss/jvm.html

 

[Roedy Green]

I read through the pdf and while helpful it didn't really touch on my
specific misunderstandings. Particularly, where/how the runtime finds
classes requested via new, and then if classes loaded by a child class
loader are at all available to classes loaded by the parent. I dont
think that part is true, but I'm seeking confirmation.

See http://mindprod.com/jgloss/classloader.html

Read up on how you write your own, and look at the how the default one
works.

A ClassLoader can get the text of the java class file in any way it
pleases, e.g. from a database, file, compose it on the fly, from jars
.... It can have dynamic classpaths, or none. Exactly how it finds
the class bytes is totally up to it.
It then feeds the byte array to a standard method
java.lang.ClassLoader.defineClass that turns it into internal machine
representation.

 

[Twisted]

It then feeds the byte array to a standard method
java.lang.ClassLoader.defineClass that turns it into internal machine
representation.

That sounds like it might be useful for having blistering fast
scripting capabilities in an app. Scripts can be compiled into actual
Java class files implementing some interface, and then potentially
into native code via Hotspot's JIT. On a server VM, and assuming
dynamically defined classes are eligible for JITting (and I don't see
why not or even how they'd be distinguished, if ALL class loading goes
eventually through this one defineClass method!), user-written scripts
would easily run as fast as natively compiled C code, if not faster
due to optimizations available only due to the optimizer having
knowledge only available at runtime (such as baking in branch
prediction into a lopsided tree structure?)...

This would be useful for spreadsheets (formula cell calculations at
native speed! Beat the crap out of excel and probably even openoffice
in speed!), math-geek software (write your own math function and use
it, and it runs as fast as C compiled with gcc -O3...make Maple and
Mathematica look like they're standing still gawping!) ...

 

[chrislewis]

Seehttp://mindprod.com/jgloss/classloader.html

Read up on how you write your own, and look at the how the default one
works.

A ClassLoader can get the text of the java class file in any way it
pleases, e.g. from a database, file, compose it on the fly, from jars
... It can have dynamic classpaths, or none. Exactly how it finds
the class bytes is totally up to it.
It then feeds the byte array to a standard method
java.lang.ClassLoader.defineClass that turns it into internal machine
representation.

Thanks for the input. I understand the idea behind a custom class
loader and defineClass. As an example I'm writing a simple test case
that, given a jar file on the cmd line, will load all .class files
into the virtual machine. The idea is basically:

1) open jar
2) enumerate jar entries
3) for each non-directory entry that ends in .class, load it

My test loader overrides no methods, and provides an addJar method for
adding jar files. addjar calls loadJarClasses:

protected void loadJarClasses(JarFile jf) {
List<String> loaded = new ArrayList<String>();
List<String> notLoaded = new ArrayList<String>();
for(Enumeration<JarEntry> jEntries = jf.entries();
jEntries.hasMoreElements() {
JarEntry je = jEntries.nextElement();
String jeName = je.getName();
if(! je.isDirectory() && jeName.endsWith(".class")) {
String fullName = jeName.substring(0, jeName.length() -
".class".length()).replace('/', '.');
try {
InputStream in = jf.getInputStream(je);
byte[] cbytes = new byte[ (int)je.getSize() /*in.available()*/];
int bread = in.read(cbytes);
in.close();
defineClass(fullName, cbytes, 0, cbytes.length);
loaded.add(fullName);
} catch (Throwable e) {
notLoaded.add(fullName);
e.printStackTrace();
}
}
}

System.out.println("\n----------------------------------");
for(String s : notLoaded) {
System.out.println("JarClassLoader.loadJarClasses() -- " + s);
}

System.out.println("\nJarClassLoader.loadJarClasses() -- loaded " +
loaded.size() + ", failed on " + notLoaded.size());
}

You'll notice i've added some debugging. The method is supposed to
load all classes in a jar when called, but as it happens, only some
get loaded. For example, when I supply js-1.6R5.jar as the jar to load
(mozilla rhino's jar), 188 classes load and 64 fail to load, with
mysterious java.lang.NoClassDefFoundError errors. The errors provide
no message save for the path name of the class and a stack trace. Any
idea as to what may be going on? I realize my example is simplistic
(currently thats the point), but I may be overlooking something.
There's really no other code that does anything useful so I didn't
include the rest.

thanks again for your input