Over the past months, I've been thinking about changing the way we generate our class files. Currently all of our class file generation is centered around producing a execute() method, with a constructor to support object initialization.
This scheme seriously limits our flexibility. Imagine a function of 2 arguments, one required and one optional. Currently, we require a call to fastProcessArgs(), where we could have done with a class which implements the single as well as the two-argument execute() methods.
Along the same lines, I'm looking to clean up our constructors: In my ideal world all the static field initializers will be moved to the class constructor <clinit>() which isn't called more than exactly once.
To support this type of output, I started jvm-class-file.lisp. It's a file which centers around generation of true class files (with arbitrary numbers of methods), instead of "functions-as-classes" which are modelled using exactly 2 methods. The jvm-class-file.lisp file is local to my working copy for now, although I did send a version to Alessio some time ago.
Apart from the flexibility this would achieve, I think I have another benefit: it would allow catching the full class file before it's a serialized. The resulting in-memory class file representation could be analysed, for example to find the stack inconsistencies we're looking (but not yet finding).
There are serveral reasons to send this mail:
1. To keep you all in the loop 2. To see about your comments regarding the above direction 3. To see if there's anybody here who wants to help out
As a general direction forward, I was thinking to start a branch so that there's some place to store my currently-private jvm-class-file.lisp. I'll have to create a BRANCH-README to document what the branch is about, what the status is and what is left to be done.
The first step forward, I'd like to do on the trunk however: a first separation of code generation and class file writing. That would allow me to write a GUI tool for inspecting the resulting class files from a single COMPILE call and hence creating a tool which should help finding our "stack inconsistency" problems.
Comments? Helpers?
Bye,
Erik.