Fail-safe way of round-tripping JVM byte-code to text-representation and back

Question

I'm looking for a fail-safe way to round-trip between a JVM class file and a text representation and back again.

One strict requirement is that the resulting round-tripped JVM class file is exactly functionally equivalent to the original JVM class file as long as the text representation is left unchanged.

Furthermore, the text representation must be human-readable and editable. It should be possible to make small changes to the the text representation (such as changing a text string or a class name, etc.) which are reflected in the resulting class file representation.

The simplest solution would be to use a Java decompiler such as JAD to generate the text representation, which in this case would simply be the re-created Java source code. And then use javac to generate the byte-code. However, given the state of the free Java decompilers this approach does not work under all circumstances. It is rather easy to create obfuscated byte-code that does not survive a full round-trip class-file/java-source/class-file (in part because there simply isn't a 1:1 mapping between JVM byte-code and Java source code).

Is there a fail-safe way to achieve JVM class-file/text-representation/class-file round-tripping given the requirements above?

Update: Before answering - save time and effort by reading all the requirements above, and note specifically:

• "Text-representation of JVM bytecode" does not necessarily mean "Java source-code".

Answer 1

Maybe I'm being overly simplistic - but have you considered using JAXB (or something along those lines) and just serializing all your classes to xml?

It's not going to work for all situations - but from your question it seems like this would be one feasible approach

Answer 2

I'm not sure if this relates to your actual requirement, but if you wish to make readable changes in source code, you must have the source code available since most decompilers will have some failing or another (considering Java 6 compatible classes not Java 1.4).

You could take a look at the BeanShell interpreter for Java, since that would allow you to make changes in the source code, without worrying about the byte code decompilation step. You could "evaluate" your source at runtime, after suitable changes have been done in the text representation. It is true that this will come at a performance cost.

Answer 3

Jasmin and Kimera?

Answer 4

No. There exists valid byte-code without a corresponding Java program.

The Soot project has a quite sophisticated decompiler- http://www.sable.mcgill.ca/dava/ - which may be useful for those byte codes coming from a Java compiler. It is, however, not perfect.

Your best bet is still getting the source code for the class files.

Answer 5

This related question might show what you're looking for.

Answer 6

The BCEL project provides a JasminVisitor which will convert class files into jasmin assembly.

This can be modified and then reassembled into class files. If no edits are made and the versions are kept compatible the the round trip should result in identical class files except that line number mapping may be lost. If you require a bit for bit identical copy for the round trip case you will likely need to alter the tool to take aspects of the code which are pure meta data as well.

jasmin is rather old and is not designed with ease of actually writing full blown programs in assembly but for modifying string constant tables and constants it should be more than adequate.