How to know a java class is compiled by jdk 64bit or 32bit version?

Question

Given a java class file, we can use hexdump or od to know its jdk version, But can we know the 64bit or 32bit information given a java class file?

I want to know if java class file has this field like version field?

If the bytecodes are agnostic of the word size, then when you od a class file, it's like:

0000000 feca beba 0000 3100 6300 0009 0019 0946 0000020 1900 4700 0009 0019 0948 1900 4900 0009 0000040 0019 094a 1900 4b00 000a 001a 074c 4d00

The first line is about 2*8 bytes, Why the second line address is 0000020?

Answer 1

But can we know the 64bit or 32bit information given a java class file?

No you cannot tell.

• Java bytecodes are "agnostic" of the word size. The same .class files can be loaded and run on either a 32 or 64 bit JVM. It doesn't matter what platform they were compiled on ¹ .
• There is nothing in the javap output that tells you what java compiler was used. (You can intuit the Java major version from the classfile version, but that's not definitive, and it is not what we are talking about ...)
• The JVM specification does not define any standard "attributes" to encode the java compiler version, or whether it was running on a 32 or 64 bit JVM.
• I couldn't find any trace of a compiler version string in a .class file using UNIX / Linux utilities such as strings or od .

Followup:

Why the second line address is 0000020?

It is in octal. Please refer to man 1 od for details. (Historically, od is a contraction of "octal dump".)

---

^{1 - Ignoring classfile version issues ...}

Answer 2

The Java .class-files are platform-independent. In particular the same class file can be executed both on 32bit and 64bit architecture. Thus there's no such field inside the class file as it's not necessary.

Answer 3

The byte code of the class file is special VM byte code and has nothing to do with the underlying architecture. Therefore you don't need to determine this information. You can compile your java program with a 64bit JDK and run it on a JRE_32 bit.