I would like extend my SQL experience.
I red so many SQL books and would like to
get more about SQL for my position as oracle database manager.

What would you recommend?

Thanks,
Werutz

Hi, I believe that if you have the same class loaded with different classloaders, there’s much more trouble than the one explained, so you won’t even get close to the stated situtation.

Quote: If there are four class loaders, there will be four copies of each one, and so on. Worse yet, these copies won’t be equal. You can easily work yourself into a place where FontStyle.ITALIC != FontStyle.ITALIC is true.

When a class is loaded by different classloaders, internally they’re different classes. So if you have one FontStyle loaded by CL1 and CL2, internally they’ll be CL1@FontStyle and CL2@FontStyle, for example. Any single class can be linked to CL1@FontStyle or CL2@FontStyle, never both, and it can’t be changed after loading. So as long as your class is linked to one of these (e.g. CL1@FontStyle) you can never access the other (e.g. CL2@FontStyle). One loaded class Font will only work with one or the other, never both. You have a problem only when a) you use reflection to access the fields, and b) you access only java.lang.Object methods, as in the given example. In this example you cannot cast the objects to FontStyle, you will see that enumTest1.isAssignableFrom(enumTest2) returns false, so you can never really use the classes. At the time you try to cast them to FontStyle, you get a ClassCastException. So it comes down to my question: is there a real world example where everything is working fine, and then you have a problem that FontStyle.ITALIC is not the same as FontStyle.ITALIC? I believe not. Please enlighten me.

If you are distributing a library, sealing your JARs would help mitigate the multiple classloader problem somewhat. To do this, simply add: Sealed: true

to your JAR’s Manifest (you can also seal a single package). If a package is sealed, then all classes loaded from that package must come from the same JAR file, otherwise the VM throws an exception. I would think this would help in the case where 2 different versions of a library that you distribute are inadvertantly included on the classpath of an application. If “EnumTest” is loaded from more than one JAR, a SecurityException should immediately flag the problem. I’d have to investigate more on which cases Sealing may or may not solve. I have a feeling it would not work for ERH’s example above and, to be frank, most of the reference material I’ve found on Sealing doesn’t discuss how it behaves with multiple classloaders. It may not help at all!

BTW, ERH - will the final XOM release be Sealed?

if (thisClassIsAlsoInAnotherLoader())
    slowerLogic();
else
    fasterLogic();

This seems like a good idea to me, since it would make the most commonly desired behaviour the easiest to implement. Can anybody think of a time when you would want something else for the exact same class in two different loaders?

Here’s a simple class that loads the same Enum class from two
different class loaders, and then compares their respective enum
constants for equality.

import java.lang.reflect.Field;
import java.net.*;
import java.io.*;

public class ClassLoaderTest {

    public static void main(String[] args)
      throws IOException, ClassNotFoundException, SecurityException,
      NoSuchFieldException, IllegalAccessException {

        URL url = new URL("http://www.cafeaulait.org/classes/");
        URL[] sources = new URL[1];
        sources[0] = url;

        URLClassLoader loader1 = new URLClassLoader(sources);
        URLClassLoader loader2 = new URLClassLoader(sources);

        Class enumTest1 = loader1.loadClass("EnumTest");
        Class enumTest2 = loader2.loadClass("EnumTest");

        Field field1 = enumTest1.getField("FIELD");
        Field field2 = enumTest2.getField("FIELD");
        Object o1 = field1.get(enumTest1);
        Object o2 = field2.get(enumTest2);

        if (o1 == o2) {
            System.out.println("Success!");
        }
        else {
            System.out.println("Failure!");
        }

    }

}

public enum EnumTest { FIELD }

You’ll need Java 1.5 to compile it.