Methoden Übernahme von standart nativen Methoden?

[Chrisi3210]

In Java habe ich unter java.lang.Double folgende native Methoden:

 public static native long doubleToRawLongBits(double value);
 public static native double longBitsToDouble(long bits);

kann ich diese mittels Copy&Paste in eigene Klassen übernehmen oder brauche ich noch dazu die
entsprechenden C++ Header Dateien, so dass ich immer den Umweg über java.lang.Double gehen muss?

 

[tfa]

Native methodendeklarationen kann man nicht einfach so kopieren.

so dass ich immer den Umweg über java.lang.Double gehen muss?

Wo ist das Problem?

 

[Chrisi3210]

Wo ist das Problem?

Dass es Entwickler gibt, die etwas unabhängiges machen wollen.
Aber wenn das nicht möglich ist, finde ich das ziemlich sch.....
:-(

 

[tfa]

Das kapier ich nicht. Willst du doubleToRawLongBits() und longBitsToDouble() benutzen oder nicht? Dann kannst du sie aufrufen wo sie definiert sind. Ich versteh nicht, was man daran "unabhängig machen" möchte.

 

[Michael...]

Dass es Entwickler gibt, die etwas unabhängiges machen wollen.
Aber wenn das nicht möglich ist, finde ich das ziemlich sch.....
:-(

Es ist ja nicht verboten die Methoden selbst zu implementieren in Java oder auch gerne nativ.

 

[mjdv]

Dass es Entwickler gibt, die etwas unabhängiges machen wollen.
Aber wenn das nicht möglich ist, finde ich das ziemlich sch.....
:-(

Irgendwie verstehe ich das Problem gar nicht. Du meinst so was wie:

double bla = Double.longBitsToDouble(5)

Ist ein Umweg?

 

[Akeshihiro]

Die Methodendeklaration einer nativen Methode aus einer Klasse in eine andere zu kopieren bringt nichts, denn es wird Exceptions hageln. Das liegt einfach daran, dass dafür die entsprechende Lib (dll, so) eingebunden werden muss. In dieser müssen die entsprechenden Methoden implementiert werden, allerdings reicht dabei nicht nur der Methodenname an sich, sondern es muss der gesamte Pfad stimmen.

Für die Methode Double.longBitsToDouble() müsste die native Methode so lauten:

java_lang_Double_longBitsToDouble

Wenn du die Methode nun in einer eigenen Klasse (mein.package.MyClass) deklarierst, dann sieht das so aus:

mein_package_MyClass_longBitsToDouble

Es reicht also nicht, dass nur die Methoden gleich heißen, es kommt auf den gesamten Pfad an.

Wenn es dir nur darum geht, dass du nicht immer die entsprechende Klasse für den Aufruf tippen willst, dann kannst du die statischen Methoden auch über einen statischen Import holen.

import static java.lang.Double.*;
// oder
import static java.lang.Double.longBitsToDouble;

Dann kannst du die Methoden aufrufen ohne die zugehörige Klasse tippen zu müssen. Man sollte davon aber nicht zu viel Gebrauch machen, das kann den Code schnell unübersichtlich machen und sobald es mehrere Klassen mit den gleichen Methoden gibt, muss man ohnehin wieder über die Klasse gehen.

Zudem ist es so, dass die Methode longBitsToDouble nunmal zur Klasse Double gehört, warum also ohne Zugehörigkeit im Raum stehen lassen? Mit Ausnahme der paar gesparten Klicks fällt mir kein sinniger Nutzen ein und ein Plus für die Übersicht ist das eigentlich auch nicht, eher im Gegenteil.

 

[Marco13]

Du kannst dir auch eine eigene JNI-Bibliothek dafür schreiben - auf C-Seite müßte das sowas sein wie
return *((long*)&someDouble);
bzw. umgekehrt :joke:

 

[pappawinni]

Wär vllt. wirklich ne gute :idea: Idee, um unabhängig zu sein, seine Programme in assembler zu codieren. Ach Shit dann ist man ja abhängig vom Prozessor und obendrein braucht man dann immernoch nen Computer. Ein Mist aber auch.;(

 

[Jango]

Wär vllt. wirklich ne gute :idea: Idee, um unabhängig zu sein, seine Programme in assembler zu codieren. Ach Shit dann ist man ja abhängig vom Prozessor und obendrein braucht man dann immernoch nen Computer. Ein Mist aber auch.;(

Blödsinn!
Man kann auch Papier und Bleistift benutzen.

@ TO:
Ich kapiere nicht, was du mit 'unabhängig' meinst. Alles ist irgendwie von einander abhängig.
Schreib eine eigene Hochsprache, die alles Andere revolutioniert...