There is a project out there called the Byte Code Engineering Library (
BCEL), these days under the Apache Jakarta umbrella. It has been around for quite a long while and is both widely used and well regarded. They have a documentation page which has some surprisingly informative background material which caught my eye.
Long as I’ve been working with Java, I’ve never bothered much learning about the internals of the language that Java Virtual Machines interpret or of how class files are laid out. The overview in the
BCEL manual of the
.class file format and how Java VMs work on bytecode is excellent — far more informative than the introductory material in the more usual official references. In particular, [section 2](http://jakarta.apache.org/bcel/manual.html#2 Java Virtual Machine), describing the general design of the Java Virtual Machine, including a section on the [Java class file format](http://jakarta.apache.org/bcel/manual.html#2.1 Java class file format), [bytecode instruction set](http://jakarta.apache.org/bcel/manual.html#2.2 Byte code instruction set) will be a fascinating read for anyone interested in language design issues.
In case you’re wondering why this came up, I’ve been working on a design review for how we might go about re-engineering
java-gnome_, and have been doing one last analysis of the more outlandish outlying possibilities (ie unlikely to be chosen, but still worth a bit more investigation). Quite a number of problems would go away if we could do runtime class generation. It might be possible through BCEL._
As it happens I am extremely reluctant to follow this path largely because it’s a hell of a lot easier to express one’s ideas in Java and let a compiler generate the bytecode than attempting to muck about with bytecode oneself. Nevertheless, it may offer a possibility in terms of things like GObject properties which are largely only available via introspection at run time.