<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Godmar Back wrote:
<blockquote
cite="mid:719dced30709261923o268d68a3ib416b1615dd56433@mail.gmail.com"
type="cite">
<pre wrap="">On 9/26/07, Mark Proctor <a class="moz-txt-link-rfc2396E" href="mailto:mproctor@codehaus.org"><mproctor@codehaus.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap=""><!---->
No, that's not how class loaders work.
A class loader, fundamentally, implements a method
</pre>
</blockquote>
Um I think I know how classloaders work, Drools does some pretty
complex class loader behaviour.<br>
<blockquote
cite="mid:719dced30709261923o268d68a3ib416b1615dd56433@mail.gmail.com"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
A user can also provide the bytecode to the classloader.<br>
<blockquote
cite="mid:719dced30709261923o268d68a3ib416b1615dd56433@mail.gmail.com"
type="cite">
<pre wrap="">
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.)
</pre>
</blockquote>
No the compiler simply needs to have the dependant class available in
the current or parent classloader, it does not need the bytecode. The
class can be dynamically added to the parent classloader, at runtime,
before you start the compilation.<br>
<blockquote
cite="mid:719dced30709261923o268d68a3ib416b1615dd56433@mail.gmail.com"
type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<br>
</body>
</html>