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
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
Update: I’ve recently stumbled over this interesting blog post about the implementation of
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
LinkedHashSets rather than just
HashSets. In terms of functional correctness of code generated during a given compile, using
HashSetwould be fine; the iteration order does not matter. However, we find it beneficial to have
javac‘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).