There are differences between the compilers and interestingly some of the permitted differences led to problems in the past.
Some differences are small, e.g. some compilers optimize x=x+1
to produce the same bytecode as x++
, others don’t.
Others can have more impact, e.g. the standard did not specify how to generate the names of synthetic members used to implement inner class access to private members (and similar things) in the past (I don’t know whether it does today). But the algorithm for calculating a default serialVersionUID
used a hash code over all class members, even synthetic ones.
As a consequence, compiling with javac
or the first Eclipse versions created classes with incompatible serialVersionUID
s. Today, Eclipse uses the same name schema for synthetic members as javac
and issues a warning about missing explicit serialVersionUID
s in Serializable
classes by default.
There’s still a lot of freedom and even packing with pack200
and unpacking may create classes with different byte code than the original classes.