On Tue, Sep 22, 2009 at 9:03 AM, Don Cohen don-sourceforge-xxz@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