On 9/26/07, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > Godmar Back wrote: > [off list] > > > Like I said, I doubt that this works. > > Classloaders don't produce the bytecode a compiler needs. It's not > part of their interface. > > Don't produce what bytecode? If you are dynnamically loading classes are > runtime, that .class has the bytecode. This is what people are doing now > already with web services. Drools has its own runtime compiler and will > compile fine against dynamically loaded classes in a parent classloader. > > No, that's not how class loaders work. A class loader, fundamentally, implements a method

public Class loadClass(String name) throws ClassNotFoundException that maps class names to class objects. For instance, the name "org.jboss.pkg.SomeClass" may be mapped to an object of type java.lang.Class - such as one that would be returned by defineClass(). Although the class loader internally reads the content of .class files - either from a URL, from a jar, or from disk, there is no interface to obtain the actual bytecode from a class loader. There is no method: "byte [] getByteCode(String name)". A class loader will internally read the (bytes constituting) a .class file, then passes it to "defineClass()", which is where the JVM parses the bytecode and creates a java.lang.Class instance.

A compiler that is compiling code that refers to a class needs access to that class's bytecode, directly. Access to a class object as provided by a ClassLoader is insufficient. (Also, it would be dangerous - reflexive examination may trigger a "first active use" (See JLS - 12.4.1 in 1st edition) - you don't want the compilation to trigger static initializers of referred classes.)

Given that, the drools compiler would need to have a way to load the actual bytecode, something a classloader cannot provide. Hence my suggestion to enhance it allow a user-controlled way of providing that bytecode. - Godmar