[armedbear-devel] Some thoughts on classloaders, ...

[Alessio Stalla]

On Tue, Sep 22, 2009 at 9:03 AM, Don Cohen
<don-sourceforge-xxz at isis.cs3-inc.com> wrote:
> Matthew D. Swank writes:
>
>  > Well in the context of abcl, a Common Lisp implementation that
>  > _targets_ the JVM, perhaps we could have a more fruitful discussion if
>  > you focus on what jvm bytecodes represent:
>  > http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html.
>  >
>  > No matter how you are interacting with a class loader, no matter what
>
> I don't understand why you have to interact with a class loader in
> order to create a compiled function.
> Perhaps you're saying that the only way to create executable code in
> JVM is via the class loader.  In other words that JVM does not support
> methods that make a compiled function object out of a byte vector, and
> doesn't even give you any way to build such a thing.  I've looked at
> the jvm spec a little, but it takes a lot of searching and analysis to
> know for sure that something like this CANNOT be done.  If it cannot
> then I would tend to view that as an unfortunate omission from the spec.
> Is there any reason the spec should not allow that?  The only thing I
> can see is that the designers of the language just didn't imagine it
> being used this way.

I'm not a language lawyer, but I have some experience in Java
programming and I assure you that the JVM cannot execute code which is
not in a method of a class. Even constructors and static
initialization blocks - which apparently by looking at the Java source
are not methods - are implemented with methods when compiled. In other
words, the JVM is natively object oriented, it has no concept of
function, only methods.

>  > the concrete representation of the byte code is in the compiler
>  > implementation, when it's loaded, when java sees it, it's all classes
>  > and methods.
>  > It's not clisp bytecode, it's not p-code, it's not even Squeak s-code
>  > (though that's probably closer), it's Java. That means the issues are
>  > very concrete: how is it possible to make compiled classes available to
>  > the JVM (presumably w/o using the file system).
> I don't see why compiled code can only come from compiled classes.
> But if all compiled code has to be in a class then I also don't see
> why compiled classes (is there any other kind?) have to come from the
> class loader.  Why are they not objects that can be created by the JVM
> by code like new Class(...).
> Perhaps that's what the class loader is,

Exactly, the classloader is the object responsible to do the
equivalent of new Class(...)

> but it only supports something like new Class(classfile) ?  Again I don't see why it should
> not support new Class on some other sort of object specifying the
> class and allowing byte vectors as the representation of compiled code.

It doesn't only supports loading from files. Out of the box there are
classloaders that know how to load code from arbitrary URLs, from JARs
inside WARs (packaged web applications), and more; you can write your
own and even generate code on the fly if you want, but, no matter
what, the end result will always be a class with methods holding the
code.

> Why should it not just allow creation of classes by new Class() and
> then allow you to add functions (and data fields, and subclasses, etc)
> to the class?

Because a Java class is unmodifiable; once loaded, it is carved in
stone. You can arbitrarily construct the bytecode representing the
class adding fields and methods as you wish, before loading it -
that's what the abcl compiler does, in fact. Adding a subclass does
not modify the superclass, you merely create a new class.

> Could this be a difference in perspective between java and lisp
> programmers/implementers/designers?

Absolutely, the JVM does not seem to have been designed with dynamic
languages in mind, although it is dynamic enough to run a Lisp...

I hope I have made things a little bit clearer.

Cheers,
Alessio