Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I was wondering if there is any good source detailing the backwards binary compatibility of java 1.4 bytecode on earlier VMs (e.g. 1.3)
I did a quick googling and I found this, but SUN is very cryptic with respect to the binary backwards compatibility.
I figure this is a great place to post this question since Retroweaver claims to resolve these problems at bytecode level.
Thanks for the help,
Xavier Le Vourch
The Java language specification and JVM specification are available on Sun's web site. The newer versions of those documents outline the differences with previous versions but if I recall correctly, there is no specific section with the changes, it's intertwined in the regular specification.
Be warned that it's not always an easy read...
I was hoping for a laundry list of compatibility issues between 1.4 and 1.3 bytecode.
I plan on using Retroweaver for my project but I need to describe the differences betwen using the 1.4 and 1.3 targets at bytecode level. So basically how will bytecode differ if I use Retroweaver's target 1.4, 1.3, 1.2. I'm only interested in format changes not API differences.
Short of digging through the Sun JVM specs then crosschecking the Retroweaver code to see how/whether that difference is addressed I was hoping that one of the developers of Retroweaver can list these issues/confirm they've been addressed since I'm sure you had to deal with them.
Here's the list of issues from the Retroweaver guide but they seem to refer to differences between 1.5 and earlier vms. Do you happen to know if the list is complete and if there is a similar on for differences between 1.4 ->1.3 and 1.3->1.2
1. Replacement of “+” characters with “$” characters in identifiers.
The new JDK 1.5 specification has relaxed the rules concerning Java
language identifiers, to allow “+” characters. Retroweaver replaces
the “+” characters with “$” characters, which are legal in earlier
virtual machines. Retroweaver also renames class files which have
“+” characters in their names.
2. Replacement of LDC and LDC_W instructions which have a
In JDK 1.5, these two instructions have been updated to work on
class literals, for example, String.class. Prior to JDK 1.5, a
programmer's use of a class literal resulted in the compiler
generation of a method to execute a Class.forName. Retroweaver
preserves the older behavior.
3. Replacement of Synthetic access specifiers with Synthetic attributes.
In JDK 1.5, Synthetic access specifiers were introduced to replace
Synthetic attributes and reduce the size of class files. Retroweaver
reverses the operation by replacing Synthetic access specifiers with
4. Removal of JDK 1.5 bit assignments from access specifiers.
The JVM specification (second edition) states that unassigned bits of
the access specifiers for classes, methods, and fields should be set
to 0 by compilers and bytecode generators. It also states that JVMs
must ignore those bits, but to be perfectly compliant, Retroweaver
resets them to 0.
Thanks for all the great work guys. Retroweaver is a really cool tool!