2 Jan 2009 05:29
Re: [groovy-user] RootLoader for system class?
Mike Dillon <mike@...>
2009-01-02 04:29:11 GMT
2009-01-02 04:29:11 GMT
begin Jochen Theodorou quotation: > Even if the system class loader did respond to loading a class we cannot > know if the loaded class is a system class or or for example simply in > the endorsed directory or whatever. A simple example si the usage of > commons-cli. We depend here on a certain version and there are other > versions around. If now such a version somehow shows up in the system > loader Groovy would probably not even start from command line anymore. Why would Groovy not start? If it's the wrong version of the library? People could stick the Groovy JAR in the endorsed directory too and it would also cause problems. I'm not sure why Groovy should be violating the ClassLoader contract here because someone might put something weird into the endorsed directory if it has the side effect of loading JDK classes from the wrong classloader. > If that wouldn't be needed RootLoader would not be needed too and it > could be a normal URLClassLoader instead... maybe not even that. > > Of course this can have other side effects as well... for example APIs > that are "suddenly" included in the jdk and where not before, but we did > need them. You have this for MX, for XML and for other things probably > too. And who knows what the future will bring here Well perhaps something like the way servlet containers handle this should be considered since they are also child-first. My understanding is that they generally have a way of switching to parent-first mode for certain packages (e.g. "java.*" and "javax.*"). If the current classloader situation is going to be maintained, it seems like pieces of code that depend on known libraries that have been integrated into some JDK version some be packaged in a separate module with JDK-specific versions. It seems from the SVN history that this was not the case with MBeanServerConnection at the time GroovyMBean was created, but it would have been great if this had been fixed at some time in the last four years since Java 5 has been out. I'm glad to hear from Paul that this particular case has been addressed for Groovy 1.6. -md --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email