überprüfte ich den Quellcode von Object Klasse, wo ich diese Methode Erklärung getClass()Warum sind die nativen Methoden hashCode() und getClass()?
public final native Class<?> getClass();
und die Erklärung von hashCode()
public native int hashCode();
Warum sind diese beiden Methoden native Methoden in der Klasse war, gefunden und Wie bekomme ich den Quellcode dieser Methoden?
Sie können den vollständigen Quellcode der nativen Methoden here
Ich hoffe, finden dies für Sie arbeiten.
Dies sind native Methoden, weil es mit der Maschine interagieren muss. Hier wird maschinenabhängiger Code in der Sprache C geschrieben, die nicht mit dem Quellpaket oder in rt.jar der Position lib der Java Runtime Environment (JRE) enthalten ist.
Ein weiterer Grund für native ist möglicherweise für die Leistung. Aufgrund der C-Ebene kann die Programmierleistung verbessert werden, daher haben sie möglicherweise den nativen Code in der C-Sprache geschrieben.
Die Methoden sind nativ, da sie systemeigene Daten betreffen. Die Methode hashCode gibt einen ganzzahligen Wert zurück, der von der internen Darstellung eines Zeigers auf ein Objekt im Heap abhängt. Die getClass-Methode muss auf das interne vtbl (virtual function table) zugreifen, das die Klassenhierarchie des kompilierten Programms darstellt. Bei Core Java ist beides nicht möglich.
'Die Methode hashCode gibt einen ganzzahligen Wert zurück, der von der internen Darstellung eines Zeigers auf ein Objekt auf dem Heap abhängt. Dies scheint nicht der Fall zu sein, wenn man die [Quelle] (http: //hg.openjdk. java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/runtime/synchronizer.cpp#l555). –
@BrianAgnew Hey, Bruder, ich habe den Code aktualisiert –
Die Informationen für diese sind in der Kopfzeile (für die Klasse) oder anderswo (für den Hash-Code) Dies können Sie nicht in Java implementieren. Die Quelle für diese Methoden befindet sich in der Quelle für die JVM. z.B. Sie können die Quelle für OpenJDK herunterladen.
Quellcode für Objektklasse kann here
Diese Quelle enthält Implementierung von getClass() Methode (siehe Zeile 58) gefunden werden. hashCode ist als Funktionszeiger JVM_IHashCode definiert (siehe Zeile 43).
JVM_IHashCode ist definiert in jvm.cpp. Siehe Code ab Zeile 504. Dies wiederum ruft den ObjectSynchronizer :: FastHashCode auf, der in synchronizer.cpp definiert ist. Siehe Implementierung von FastHashCode in Zeile 576 und get_next_hash in Zeile 530.
Wahrscheinlich sind die Methoden native für die Leistung und aufgrund praktischer Probleme w.r.t Implementierung.
Für z. B. Von javadocs wird hashCode typischerweise "durch Umwandlung der internen Adresse des Objekts in eine ganze Zahl" implementiert. Diese interne Adresse ist nicht über Java SDK verfügbar und muss als native Methode implementiert werden.
Bitte lesen Sie Is it possible to find the source for a Java native method?. Lesen Sie auch diesen Blogpost Object.hashCode implementation. Es gibt mehr Details. Aber es wird falsch behauptet, dass hashCode nicht aus der Identität des Objekts generiert wird.
Ich hoffe, es hilft.
Wie können wir dann sagen, dass JVM plattformunabhängig ist? –
Wie würde dies die Plattformunabhängigkeit zerstören? Für jedes Objekt muss hashCode nicht plattformübergreifend gleich sein. Auf der gleichen Plattform, über verschiedene Läufe hinweg, ist es nicht einmal dasselbe. Versuchen Sie die öffentliche Klasse TestHashCode { public static void main (Zeichenfolge [] args) { Objekt o = new Object(); System.out.println (o.hashCode()); } } – krishnakumarp
@BhavikAmbani Dies ist Terminologie Nitpicking, aber * JVM * ist nicht plattformunabhängig, sondern eher der plattformabhängige Teil, der den plattformunabhängigen Java-Bytecode auf einer gegebenen Plattform ausführt. – hyde
kein Duplikat - das OP weiß, was nativ ist, will aber wissen, warum diese beiden Methoden spezifisch sind. – Alnitak
hashCode() ist nativ, da die Art und Weise, wie Daten gespeichert werden, auf unüblichen Betriebssystemen unterschiedlich sein kann. Ich bin mir nicht sicher, warum getClass() ist; möglicherweise aufgrund unterschiedlicher Implementierungen von Polymorphismus. – Vulcan
@Vulcan getClass() ist endgültig, Sie können es also nicht überschreiben und das Typsystem unterbrechen. – EJP