修改HelloWorld.class后执行报错，Java如何识别类文件的变更？

Let's break down what's happening here, and how Java's JVM checks the validity of .class files—including detecting unauthorized or broken modifications.

First, that UnsupportedClassVersionError you're seeing is a bit of a red herring. It usually pops up when you try to run a class compiled with a newer JDK on an older JVM, but in your case, it's actually a side effect of you breaking the binary structure of the .class file when you manually edited the string.

How Java (JVM) Detects Modifications to .class Files #

The JVM doesn't just "scan" for changes—it enforces strict compliance with the Java Class File Format specification during loading. Here are the key checks that caught your modified file:

• Magic Number & Version Check
  Every valid .class file starts with a 4-byte "magic number": 0xCAFEBABE. Right after that are 4 bytes representing the class file version (minor version first, then major). If your manual edit shifted bytes accidentally, or you touched these bytes by mistake, the JVM will misinterpret the version number (or think the file is invalid entirely) and throw that version error. Even if you didn't touch these bytes, a broken structure elsewhere can cause the JVM to read wrong data as the version field.

• Constant Pool Integrity
  Your "Welcome message" string lives in the class file's constant pool—a table of all literal values used by the class. Each string in the pool is stored as a CONSTANT_Utf8_info entry, which has a strict structure:

  1-byte tag (0x01) + 2-byte length + [length]-byte string content
  

  If you changed the string content but didn't update the 2-byte length field to match the new string's length, the JVM will read past the actual string into other parts of the class file. This corrupts the entire parsing process, often leading to unexpected errors like the version mismatch you saw.

• Structural Byte Alignment
  The entire .class file is a tightly packed binary format, with every section (class metadata, method definitions, attributes) having defined lengths and offsets. Manual edits almost always throw off these offsets—for example, adding or removing bytes in one section makes all subsequent sections shift, so the JVM reads incorrect data for fields like access flags, method counts, or even the version number.

• Bytecode Verification
  After parsing the class structure, the JVM runs a bytecode verifier that checks things like valid instruction sequences, proper stack usage, and type safety. A corrupted class file will fail this verification step, and the JVM will refuse to load it (again, sometimes with a misleading error message like the version one).

Fixing Your Issue #

If you want to modify the string in your class file, don't edit the binary manually. Instead:

• Modify the original .java source file and recompile it (the simplest and safest approach).
• Use a dedicated bytecode manipulation library like ASM or Javassist—these tools handle all the structural details (like updating constant pool lengths) automatically, so you don't break the class file.

内容的提问来源于stack exchange，提问作者Prasad