Let’s put it this way:
I can easily produce an entirely conforming Java compiler that never produces the same .class
file twice, given the same .java
file.
I could do this by tweaking all kinds of bytecode construction or by simply adding superfluous attributes to my method (which is allowed).
Given that the specification does not require the compiler to produce byte-for-byte identical class files, I’d avoid depending such a result.
However, the few times that I’ve checked, compiling the same source file with the same compiler with the same switches (and the same libraries!) did result in the same .class
files.
Update: I’ve recently stumbled over this interesting blog post about the implementation of switch
on String
in Java 7. In this blog post, there are some relevant parts, that I’ll quote here (emphasis mine):
In order to make the compiler’s output predictable and repeatable, the maps and sets used in these data structures are
LinkedHashMap
s andLinkedHashSet
s rather than justHashMaps
andHashSets
. In terms of functional correctness of code generated during a given compile, usingHashMap
andHashSet
would be fine; the iteration order does not matter. However, we find it beneficial to havejavac
‘s output not vary based on implementation details of system classes .
This pretty clearly illustrates the issue: The compiler is not required to act in a deterministic manner, as long as it matches the spec. The compiler developers, however, realize that it’s generally a good idea to try (provided it’s not too expensive, probably).