Generating JVM bytecode 4- April 26, 2008 GCJ lets you compile your Java program to a native executable. This can be handy, but this isn't as handy as you might think in relation to generating JVM bytecode.A GCJ-compiled program starts quickly, and can be used in places where you can't use a JAR file or a shell script wrapper (the two most common choices for launching Java programs), but when you start to execute your generated bytecode, you'll notice that code runs pretty slowly. About the same speed as most interpreters seem to run...http://elliotth.blogspot.com/2008/04/generating-jvm-bytecode-4.html Generating JVM bytecode 3- April 14, 2008 ASM, gnu.bytecode, and org.mozilla.classfile: a comparisonI explained earlier that I chose ASM over BCEL because the latter has a reputation for being big and slow, while the former makes a big thing of being smaller and faster. Plus ASM has better documentation.There are other choices, though. You can write your own library, for example. From the various implementations I've seen, I reckon that's about 3000 lines of work. If that end of things interests you, go for it. But it's not obvious...http://elliotth.blogspot.com/2008/04/generating-jvm-bytecode-3.html Generating JVM bytecode 2- April 1, 2008 Constant poolsIf you're compiling a language other than Java, you may find the fact that the class file constant pool can only contain JVM primitive types or instances of java.lang.String somewhat frustrating. I wanted a constant pool for my boxed integers and boxed reals.Disappointingly, the "getstatic", "bipush", "aaload" to load a boxed real constant from my private static final Object home-made "constant pool" seems to perform about the same as the "ldc" and "invokestatic" for boxing a JVM..http://elliotth.blogspot.com/2008/03/generating-jvm-bytecode-2.html |