Вопрос по java, c, c++ – Почему методы hashCode () и getClass () являются нативными?

32

Я проверил исходный кодObject класс, где я нашел объявление этого методаgetClass() было

public final native Class<?> getClass();

И декларацияhashCode() было

public native int hashCode();

Почему эти два методаnative методы в классе, и как я могу получить исходный код этих методов?

не дубликат - ОП знает, что такое родной, но хочет знатьwhy эти два метода конкретно. Alnitak
@Vulcan getClass () является окончательным, поэтому вы не можете переопределить его и нарушить систему типов. user207421
hashCode () является родным, потому что способ хранения данных может отличаться в разных операционных системах. Я не уверен, почему getClass (), хотя; возможно из-за различных реализаций полиморфизма. Vulcan
@ EJP Я знаю, почему он окончательный, но не, почему он родной. Как я сказал в своем последнем комментарии, мое единственное предположение будет связано с различными реализациями полиморфизма. Vulcan
Что ж,hashCode может быть реализовано сSystem.identityHashCode. zch

Ваш Ответ

3   ответа
2

те (для hashCode). Это не то, что вы можете реализовать в Java. Источник для этих методов находится в источнике для JVM. например Вы можете скачать исходный код OpenJDK.

40

Вот

Я надеюсь, что это будет работать для вас.

Это нативные методы, потому что он должен взаимодействовать с машиной. Здесь машинно-зависимый код написан на языке C, который не поставляется с исходным пакетом или вrt.jar изlib расположениеJava Runtime Environment (JRE).

Еще одна причина быть родной, возможно, из-за производительности. Благодаря повышению производительности программирования на уровне C, возможно, они написали собственный код на языке C.

Методы являются родными, потому что они касаются собственных данных.hashCode Метод возвращает целочисленное значение, зависящее от внутреннего представления указателя на объект в куче.getClass метод должен получить доступ к внутреннемуvtbl (таблица виртуальных функций), который представляет иерархию классов скомпилированной программы. Ничто из этого невозможно с ядром Java.

The hashCode method returns an integer value dependent on the internal representation of a pointer to an object on the heap. Это не похоже на то, чтобы смотреть наsource.
@BrianAgnew Эй, братан, я обновил код
33

Вот

Этот источник содержит реализацию метода getClass () (см. Строку 58). hashCode определяется как указатель на функцию JVM_IHashCode (см. строку 43).

JVM_IHashCode определен вjvm.cpp, См. Код, начинающийся со строки 504. Это, в свою очередь, вызывает ObjectSynchronizer :: FastHashCode, который определен вsynchronizer.cpp, Смотрите реализацию FastHashCode в строке 576 и get_next_hash в строке 530.

Вероятно, эти методы являются родными для производительности и из-за практических проблем с реализацией.

Например, из javadocs hashCode обычно реализуется "путем преобразования внутреннего адреса объекта в целое число". Этот внутренний адрес не доступен через Java SDK и должен быть реализован как собственный метод.

Пожалуйста, прочитайтеМожно ли найти источник для нативного метода Java?, Также прочитайте этот пост в блогеРеализация Object.hashCode, Это дает больше деталей. Но делает неправильное утверждение, что hashCode не генерируется из идентичности объекта.

Надеюсь, поможет.

Как это нарушит независимость платформы? Для любого объекта hashCode не обязательно должен быть одинаковым на разных платформах. В этом отношении он даже не будет одинаковым на одной и той же платформе для разных прогонов. Попробуйте открытый класс TestHashCode {public static void main (String [] args) {Object o = new Object (); System.out.println (o.hashCode ()); }}
@BhavikAmbani Это придирка к терминологии, ноJVM не является независимой от платформы, а скорее зависимой от платформы частью, которая выполняет независимый от платформы байт-код Java на данной платформе.
@hyde Вот что я говорю, см. мой ответ.
Тогда как мы можем сказать, что JVM не зависит от платформы?

Похожие вопросы