[Java] Platformunabhängige Pointer in JNI?

[Lin728]

Hi there!

Normalerweise kann man ja pointer in JNI mit einem int in Java realisieren, man übergibt der C-Funktion einfach das int und in der C-Funktion declariert man, dass dieses int ein pointer ist.
So gesehen ist dieses int also ein void*, soweit ich das richtig verstanden habe.

Jetzt habe ich aber das Problem, dass dieses Vorgehen nur auf 32-bit Maschienen funktioniert, da sich auf 64-bit Maschinen zwar die Pointerlänge verdoppelt, aber die anzahl der bytes pro int gleich bleibt...

Da Sun mit dem JDK-1.4 das AWT auch 64-BIT tauglich gemacht haben, weiß wer wie das funktionieren könnte?

Mfg

[anda_skoa]

Ich glaube der Java int ist immer 8 Bytes lang, man darf halt C seitig keinen int verwenden.

Normalerweise ist long immer so groß wie der Pointer der Architektur. Ist zwar AFAIK kein Standard, aber bei allen mir bekannten C Compilern der Fall.

Eventuell bringts auch was, in den Sourcen diverser Bindings nachzusehen, die müssen das ja auch gelöst haben.

Ciao,
_

[Lin728]

Hab herausgefunden, dass das mit dem "genormten" 1.1 JNI gar nicht geht.

lg

[peschmae]

dann ists ja kein Problem - CNI soll eh schneller sein ;)

MfG Peschmä

[anda_skoa]

Was ist CNI?

Ciao,
_

[Lin728]

Grüssi!

GCJ bringt extra ein Pointer-Object (gnu.gcj.RawData) mit, mit dem lassen sich Referenzen platformunabhängig verwalten.
Das ganze Funktioniert mit JNI und CNI.

Zu CNI:
CNI ist die nativ/Java Schnittstelle des GCJ (dieser unterstützt aber auch JNI).
CNI teilt sich die ABI von G++ und GCJ, d.h. man kann z.B. in C++ Methoden und Klassen schreiben, die aus dersicht von GCJ genauso behandelt werden, wie kompilierte java-klassen.

Es lassen sich dann solche netten Dinge machen:


java:
public class javaklasse
{
native static synchronized void sayHello();
}

C++:
#include <gcj/cni.h>
#include <javaklasse.h>

javaklasse::sayHello()
{

}

[Lin728]

Grüssi!

GCJ bringt extra ein Pointer-Object (gnu.gcj.RawData) mit, mit dem lassen sich Referenzen platformunabhängig verwalten.
Das ganze Funktioniert mit JNI und CNI.

Zu CNI:
CNI ist die nativ/Java Schnittstelle des GCJ (dieser unterstützt aber auch JNI).
CNI teilt sich die ABI von G++ und GCJ, d.h. man kann z.B. in C++ Methoden und Klassen schreiben, die aus dersicht von GCJ genauso behandelt werden, wie kompilierte java-klassen.

Es lassen sich dann solche netten Dinge machen:


java:
public class javaklasse
{
native static synchronized void sayHello();
}

C++:
#include <gcj/cni.h>
#include <javaklasse.h>

javaklasse::sayHello()
{
printf("Hallo!");
}


Der grund warum ichs jetzt doch JNI mache, ist, dass die Kaffe-Bindings schon in JNI geschrieben sind, wenn auch nicht portabel.
Da CNI ja C++ ist, müsste ich den ganzen nativen Teil neu schreiben.

Mfg Clemns

[anda_skoa]

Original geschrieben von ceisserer
Zu CNI:
CNI ist die nativ/Java Schnittstelle des GCJ (dieser unterstützt aber auch JNI).
CNI teilt sich die ABI von G++ und GCJ, d.h. man kann z.B. in C++ Methoden und Klassen schreiben, die aus dersicht von GCJ genauso behandelt werden, wie kompilierte java-klassen.


Ah, das ist cool!
Spart man sich das Herumspielen mit der C API. Edel!

Ciao,
_

[Lin728]

Grüssi!

Heute Abend konnte ich zum Ersten ein Fenster dazu überreden, aufzugehen.

Eigentlich ist bereits fast alles Funktionsfähig (Buttons, Label, GridBagLayout, EventListener)- es gibt lediglich noch verify-errors die hin und wieder von GIJ geworfen werden und image-loading funktioniert noch nicht.
Hab nen Screenshot drangehängt ;-)

lg

[peschmae]

Toll

(Soll ich dir wirklich glauben dass das GCJ war? ;))

Schon was einigermassen verlässliches zu den Lizenzfragen (GPL <-> LGPL) gehört?

MfG Peschmä

[Lin728]

Hi!


Das Bild da oben stammt von GIJ, die ersten nativen Builds haben heute angefangen zu linken und funktionieren gut.
Die verify-errors sind bugs von GIJ ;-)
Image-Loading funktioniert jetzt für PNG, GIF kommt nicht rein, JPG hat derzeit noch ein paar probleme auf der C-Seite.

Soweit ich weiß, steht Kaffe unter LGPL sowie der ganze Kaffe-Classpath, ich muss allerdings noch fragen. Hoffentlich stellen sich da keine großen Probleme heraus...

Mfg

[peschmae]

uups, stimmt, du hattest gij geschrieben :D

naja, ich denke beides ist interessant - aber gcj ein bisschen mehr da awt auf einer jvm ja auch bei Sun erhältlich ist :)

Natürlich ist gij Freie Software aber in diesem Fall sind die Vorteile natürlich nicht soo extrem

MfG Peschmä

[Lin728]

, hat noch kein Build-system. Viel Spaß beim kompilieren:

xawt.sourceforge.net

[peschmae]

könntest du aus den Downloads noch

die xawt0.1 zu der keine Dateien gehören löschen?

Ich bin glücklich zu sehen, dass ich nicht der einzige bin, der mit den Features von Sourceforge kämpft :D :D

Zum Build-System: Leider habe ich keine Ahnung von Automake (sollte man auch mal ändern ;)) - das höchste der Gefühle war bisher ein Makefile für meine GCJ-SWT-App das tatsächlich nur die Objekte neu erstellt, deren Sourcen geändert wurden :) :)

War ne heidenarbeit :eek: :mad:

Ich sollte mir glaub ich mal Helmut Herolds "make"-Büchlein kaufen - dann ginge sowas wohl besser.

MfG Peschmä

[Lin728]

Hi!

Ich hab ehrlich schon überlegt, ob ich mir nicht auf geocities ne seite anlege, weil CVS kann ich eh nicht, und das fileuploaden war sowas vom umständlich.

lg