Hot Deployment & ClassLoader Re-Use

Question

I've implemented a service that observes changes to a jar file's timestamp, and utilizes a new UrlClassLoader to hot deploy class changes. It's working well in isolation, but I wonder how it will perform in production. The work is based on the October 31, 2000 JDC Tech Tips ( http://java.sun.com/developer/TechTips/2000/tt1027.html ).
I've tried to improve on the example code and I wonder if my change will help or haunt me. The example creates a new URLClassLoader every time the class is requested by name. In comparison, I wanted to only create a new class loader when necessary. To do so, I collect the class loader used for a given class name and re-use it on the next request if the underlying jar file has not changed. Is this a wise approach? Anything else I should be thinking about?
Here's some sample code to illustrate:
    protected HashMap jarMap = null;
    protected HashSet classesUpgraded = null;
    protected HashMap classLoaders = null;
    protected IUpgradeObserver observer = null;
    public Class getClass(String xtlClassName) throws ClassNotFoundException {
        Class c = null;
        File f = getJar(xtlClassName);
        observer.notifyIfChanged(f);
        try {
            if(f != null) {
                lazyInitClassesUpgraded();
                if(classesUpgraded.contains(xtlClassName)) {
                    // the jar has changed, so create a new class loader
                    Dbug.print(dbugTag, "Reloading " + xtlClassName + " from jar with timestamp " + f.lastModified());
                    ClassLoader loader = new URLClassLoader(new URL[]{f.toURL()});
                    c = loader.loadClass(xtlClassName);
                    if (c != null) {
                        classesUpgraded.remove(xtlClassName);
                        lazyInitClassLoaders();
                        classLoaders.put(xtlClassName, loader);
                } else {
                    // the class has already been loaded from the current jar - reuse the existing class loader
                    lazyInitClassLoaders();
                    ClassLoader loader = (ClassLoader)classLoaders.get(xtlClassName);
                    c = loader.loadClass(xtlClassName);
        } catch (MalformedURLException urle) {
            urle.printStackTrace();
        if(c == null) {
            throw new ClassNotFoundException("The Xtencil jars did not contain " + xtlClassName);
        } else {
            return c;
    }

Answer 1

legosa - Sure, some portion of getClass must be synchronized to reduce the likelihood of an additional new class def being created when two threads enter getClass at the same time. The other points you make are good as well, and I initially became aware of them in reading the Sun example. As far as I can tell, they shouldn't affect us. I'm not writing a general-purpose class loader. My work is only used to load a specific type of "map" that is frequently updated. We always go through the same factory function to create these maps by name. No singletons will be generated through the utility, and it should be fine for two class objects to exist for a given class name. Basically, the software looks up a map implementation by name, runs it, marks the map as garbage, and moves on to the next. If I plug my class loader into our other web-based container, I have more concerns, since many users may be requesting maps and the old class definitions are less likely to be garbage at any given time.
pekoe - Thanks for the heads up on HotSwap. Unfortunately, as I understand it, the work is intended for development environments, not production servers. For example, it requires the JVM be in debug mode!