.java中的注释更改.class文件的ByteCode

Question

My understanding is that the Java compiler does not include comments in bytecode in the output .class file.

However I have the code:

InputStream stream = getClassLoader().getResourceAsStream(classAsPath);
byte[] classBytes = IOUtils.toByteArray(stream);

I run it for my java class, add a comment to the java code, and re-run it. I see that classBytes is different just from the added comment

Answer 1

Comments are not included in the classfile. However, the compiler does by default include some metadata for debugging purposes, which includes line numbers. If your comments span a line or more, that will obviously change the line numbers of everything, and hence the resulting classfile will change.

You can pass -g:none to javac to avoid including line numbers and other optional metadata.

Answer 2

There is no guaranty that the same source code produces exactly the same byte code. The standard does not mandate how certain language constructs are mapped to byte code constructs and certain “best practices” have changed over time or differ between compiler implementations. Some aspects, eg the order of the methods within a class file are considered entirely irrelevant and may be the result of some implementation specific aspects of the compiler instead of a deliberate decision.

Usually, using exactly the same compiler implementation and version will reproduce the same byte code, as the compiler's program code is deterministic, but that doesn't have to be, eg some hash map implementations have a randomization feature, also compilers might utilize parallel processing which may add indeterminism to aspects considered irrelevant to the result.

Given that even exactly the same source code is not guaranteed to produce identical bytecode, it should not surprise that even small, actually irrelevant changes may cause differences in the bytecode, as even if nothing else changes they may have an impact on timing or hash codes.

As said by others, inserting a comment line may change the line numbers in debug attributes which are included by default, so that's a simple reason to get different byte code. But it is important to understand that your assumption to always get identical byte code is fundamentally flawed.

Note that a similar wrong assumption has already led to a major design flaw in the Java API. The default serialVersionUID is calculated by hashing class data which are actually irrelevant to the compatibility of serialized data. As the documentation of Serializable states:

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization.

Don't repeat this mistake.