Sprawdziłem kod źródłowy Object klasy gdzie odkryłem, że deklaracja metoda getClass() byłDlaczego są metody natywne hashCode() i getClass()?
public final native Class<?> getClass();
i deklarację hashCode() był
public native int hashCode();
Dlaczego te dwie metody native metody w klasie i jak mogę uzyskać kod źródłowy tych metod?
można znaleźć kompletny kod źródłowy rodzimych metod here
Mam nadzieję, że będzie pracować dla Ciebie.
Są to metody natywne, ponieważ muszą wchodzić w interakcje z urządzeniem. Tutaj kod zależny od komputera jest napisany w języku C, który nie pochodzi z pakietu źródłowego ani z rt.jar z lib lokalizacji Java Runtime Environment (JRE).
Kolejny powód bycia tubylcem wynika prawdopodobnie z wydajności. Ze względu na wydajność programowania na poziomie C można poprawić, dlatego mogą napisać natywny kod w języku C.
Metody są natywne, ponieważ dotyczą danych natywnych. Metoda hashCode zwraca wartość całkowitą zależną od wewnętrznej reprezentacji wskaźnika do obiektu na stercie. Metoda getClass musi uzyskać dostęp do wewnętrznego vtbl (virtual function table), który reprezentuje hierarchię klas skompilowanego programu. Żadne z nich nie jest możliwe z rdzeniem Java.
'Metoda hashCode zwraca wartość całkowitą zależną od wewnętrznej reprezentacji wskaźnika do obiektu na stercie." Nie wygląda to tak, patrząc na [źródło] (http: //hg.openjdk. java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/runtime/synchronizer.cpp#l555). –
@BrianAgnew Hej, bracie, zaktualizowałem kod –
Informacje na ten temat znajdują się w nagłówku (dla klasy) lub w innym miejscu (dla parametru hashCode). Nie można tego zaimplementować w Javie. Źródło tych metod znajduje się w źródle JVM. na przykład możesz pobrać źródło dla OpenJDK.
kod źródłowy dla klasy Object można znaleźć here
To źródło zawiera implementację metody getClass() metoda (patrz linia 58). hashCode jest zdefiniowany jako wskaźnik funkcji JVM_IHashCode (patrz wiersz 43).
JVM_IHashCode jest zdefiniowany w jvm.cpp. Zobacz kod zaczynający się od wiersza 504. To z kolei wywołuje ObjectSynchronizer :: FastHashCode, który jest zdefiniowany w synchronizer.cpp. Zobacz implementację FastHashCode w linii 576 i get_next_hash w linii 530.
Prawdopodobnie metody te są natywne dla wydajności i ze względu na praktyczne problemy z implementacją w.r.t.
Dla np. Z javadocs, hashCode jest zwykle implementowany "przez konwersję wewnętrznego adresu obiektu na liczbę całkowitą". Ten wewnętrzny adres nie jest dostępny przez java sdk i będzie musiał zostać zaimplementowany jako natywna metoda.
Proszę przeczytać Is it possible to find the source for a Java native method?. Przeczytaj także ten wpis na blogu: Object.hashCode implementation. Daje więcej szczegółów. Ale robi błędne twierdzenie, że hashCode nie jest generowane z tożsamości obiektu.
Mam nadzieję, że to pomaga.
Więc jak możemy powiedzieć, że JVM jest niezależna od platformy? –
Jak by to przełamać niezależność platformy? Dla dowolnego obiektu hashCode nie musi być taki sam na różnych platformach. W tym przypadku nie będzie to samo na tej samej platformie, w różnych seriach. Wypróbuj public class TestHashCode { public static void main (String [] args) { Obiekt o = new Object(); System.out.println (o.hashCode()); } } } – krishnakumarp
@BhavikAmbani To jest garbowanie terminologii, ale * JVM * nie jest niezależny od platformy, ale raczej jest to część zależna od platformy, która wykonuje niezależny od platformy kod bajtowy Java na danej platformie. – hyde
nie jest duplikatem - OP wie, czym jest natywa, ale chce wiedzieć, dlaczego są dokładnie te dwie metody. – Alnitak
hashCode() jest natywny, ponieważ sposób przechowywania danych może się różnić w różnych systemach operacyjnych. Nie jestem pewien, dlaczego getClass() jest; prawdopodobnie z powodu różnych implementacji polimorfizmu. – Vulcan
@Vulcan getClass() jest ostateczny, więc nie można go przesłonić i przerwać system typów. – EJP