FWIK Java can run on 64-bit system, no problem.

Correct

I'd like to know how Java support 64-bit features.

Java supports 64 bit in a way that introduces no behavioural differences. A Java program will run on 32 bit or 64 bit platforms without change. All of the primitive types are the same, all of the APIs are the same.

System.identityHashCode() returns a 32-bit int, it's common to see the object pointer (memory address) is returned.

Inaccurate. What you see is a value that may or may not be related to the object's memory address at some time in the object's lifetime. Even if it is a memory address, it can't be used as one. There's no way to turn the int value back into a reference in pure Java. (Even with JNI / JNA it would be highly unreliable ... so don't think about doing it!)

An identity hashcode is a "uniquish" number. That's all.

Should 64-bit Java returns long instead?

No. That would make the class libraries different for 32 bit and 64 bit Java and prevent the same binary code from running on either platform.

If not, how would Java scale to 64-bit systems?

It just does. There are one or two "issues". For instance array sizes and string lengths are limited to 32-bit int values. These mean that you can't fully exploit the hardware; e.g. you can't arrays with more than 2^31 elements on a 64-bit JVM. (But if you could, there would be binary compatibility problems ...)

The identityHashCode return type is not a real issue because the value is NOT guaranteed to be related to machine address, and you can't be used as a machine address either.

FWIK Java can run on 64-bit system, no problem.

Correct.

I'd like to know how Java support 64-bit features.

Java supports 64 bit in a way that introduces no behavioural differences. A Java program will run on 32 bit or 64 bit platforms without change. All of the primitive types are the identical, the class library APIs are identical, the bytecode formats are the same. As far as the program is concerned, the only difference is that you can allocate more things before your heap fills up.

System.identityHashCode() returns a 32-bit int, it's common to see the object pointer (memory address) is returned.

Inaccurate. What you see is a value that may or may not be related to the object's memory address at some time in the object's lifetime. Even if it is a memory address, it can't be used as one. There's no way to turn the int value back into a reference in pure Java. (Even with JNI / JNA it would be highly unreliable ... so don't think about doing it!)

An identity hashcode is a "uniquish" number. That's all.

Should 64-bit Java returns long instead?

No. That would make the class libraries different for 32 bit and 64 bit Java and prevent the same code from running on either platform.

If not, how would Java scale to 64-bit systems?

It just does. There are one or two "issues". For instance array sizes and string lengths are limited to 32-bit int values. These mean that you can't fully exploit the hardware; e.g. you can't arrays with more than 2^31 elements on a 64-bit JVM. (But if you could, there would be compatibility problems between 32 bit and 64 bit JVMs and applications designed to run on the two flavours.)

The identityHashCode return type is not a real issue because the value is NOT guaranteed to be related to machine address, and you can't be used as a machine address either.