Godmar Back wrote: 
PS: I looked at what Drools does in the Eclipse compiler configuration.

It appears to assume that a class's bytecode can be found as a system
resource, via getResourceAsStream(). See
org.drools.common.jci.compilers.EclipseJavaCompiler.java.

In other words, if the compiler asks for the byte code for Class
org.jboss.somepackage.SomeClass, Drools will ask the class loader for
the resource with path "org/jboss/somepackage/SomeClass.class".
Although most class loaders would at this point return an InputStream
from which the bytecode of this class can be read, there is no
requirement that they do so - or that this resource exists at all. For
instance, class loaders that rewrite bytecode on the fly would provide
different bytecode from this system resource than otherwise.

Nevertheless, it is a reasonable assumption, and it means that
implementing the import from functionality may not be difficult. I'm
getting the feeling though, that you have doubts about its usefulness.

 - Godmar
Again you are reading this wrong, I think you have a fundamental misunderstanding of how classloaders work in Java. See my previous email. Simple add the class at runtime to a classloader and use that classloader as the root classloader of the packagebuilder.
On 9/26/07, Godmar Back <godmar@gmail.com> wrote:
  
On 9/26/07, Mark Proctor <mproctor@codehaus.org> 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