Lambda the Ultimate

BCEL has its rough edges, but it's generally nice to use, and it's a great asset to Java. It adds an entirely new order of flexibility to Java.

We are currently using it to instrument EJB's as they are loaded into an App-Server (demonstrating BCEL's round-tripping) and to translate Java bytecode into Macromedia Flash bytecode (demonstrating its use for static analysis).

Are these VMs similar in any way?

This is particularly interesting to me because I've actually been working on a "hobby project" to translate Flash SWF files into XML and back. My intent was to create a "Flash Intermediate Language" (like Microsoft's MSIL) to allow various frontends generate the intermediate XML, allowing non-Macromedia languages to create Flash movies. :-)

Flash Player bytecode is designed to support Action Script - which is a subset of ECMA/JavaScript - in the same way as JVM Bytecode is designed to support Java. If you imagine the differences between the two languages you will have a reasonable understanding of the differences between the two VMs.

Both are stack-based machines. The Flash VM only has 4 registers (whereas the JVM has as many as you need) but makes up for that with named local variables (i.e. the ECMA "var" construct). Flash bytecode is not typed - so, for example, all the different JVM add instructions (IADD, DADD, FADD, LADD) can be mapped to a single Flash add instruction. The only major difficulty in mapping JVM bytecode to Flash at the lowest level is that method arguments are pushed onto the stack right-to-left in Flash and left-to-right in Java. The early experiments generated Flash bytecode to pop and then push the args in reverse order before each method call. The current approach is to reduce the stack-based JVM code to an expression tree format so that the reordering can be done in the translator rather than the generated code (although this changes the semantics of the Java source code wrt parameter evaluation order).

There are other differences that should be obvious - synchronization, exceptions, in-method subroutines (Flash has none of these). Overall, though, the mapping from one VM to the other is useful.

The target version is Flash 6 (MX) and the goal is to provide the capability to do most of what you can in ActionScript by writing Java code against a set of Java classes that mimic the runtime library in the Flash player. A longer-term goal is to translate arbitrary Java code and use the Flash player to run Applets.

This project is based on the JavaSWF library and will most likely be released as part of that (under the same BSD-style license).

BTW - JavaSWF already has a SWF --> XML --> SWF capability - although it is not well documented.

http://www.anotherbigidea.com/javaswf/

Full disclosure: I work as an engineer on Macromedia's Flash Player team. :-)