Lambda the Ultimate

inactiveTopic Byte Code Engineering Library
started 3/5/2003; 7:12:24 AM - last post 3/7/2003; 1:44:53 PM
Ehud Lamm - Byte Code Engineering Library  blueArrow
3/5/2003; 7:12:24 AM (reads: 2776, responses: 8)
Byte Code Engineering Library
The Byte Code Engineering Library (formerly known as JavaClass) is intended to give users a convenient possibility to analyze, create, and manipulate (binary) Java class files (those ending with .class). Classes are represented by objects which contain all the symbolic information of the given class: methods, fields and byte code instructions, in particular.

I don't think we mentioned this before, and it does look like a useful tool.

Among the projects using BCEL, you may find the following especially interesting: Poor Man's Genericity, Portable JRAF, Funnel, Kava and Sally.

Posted to implementation by Ehud Lamm on 3/5/03; 7:15:23 AM

Toby Reyelts - Re: Byte Code Engineering Library  blueArrow
3/5/2003; 7:36:10 AM (reads: 1637, responses: 0)
You can add Jace,, to that list. It uses BCEL to enhance the byte code of Java Peer classes to add transparent lifetime management for C++ JNI peers.

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.

nickmain - Re: Byte Code Engineering Library  blueArrow
3/5/2003; 12:29:17 PM (reads: 1565, responses: 1)
I can attest to the usefulness of BCEL. The way it models bytecode instructions, with the added ability to match instruction sequences using a Regular-Expression based syntax, is very powerful.

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).

Ehud Lamm - Re: Byte Code Engineering Library  blueArrow
3/5/2003; 1:58:41 PM (reads: 1572, responses: 0)
Java bytecode into Macromedia Flash bytecode

Are these VMs similar in any way?

Chris - Re: Byte Code Engineering Library  blueArrow
3/5/2003; 6:27:44 PM (reads: 1510, responses: 0)
What version of Macromedia Flash bytecode are you targetting? How is the performance of "Java on Flash"?

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. :-)

bryan rasmussen - Re: Byte Code Engineering Library  blueArrow
3/6/2003; 8:37:35 AM (reads: 1428, responses: 0)
chris- you might like to look at and a related project deng:

nickmain - Re: Byte Code Engineering Library  blueArrow
3/6/2003; 10:09:55 AM (reads: 1412, responses: 2)
>> Are these VMs similar in any way?

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.

Chris - Re: Byte Code Engineering Library  blueArrow
3/6/2003; 3:31:39 PM (reads: 1413, responses: 0)
Wow, that is an impressive feat! JavaSWF is exactly what I was trying to create (in C++). How much slower is the converted Flash code compared to the original Java code?

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

Ehud Lamm - Re: Byte Code Engineering Library  blueArrow
3/7/2003; 1:44:53 PM (reads: 1359, responses: 0)
Thanks. This is all very enlightening.