Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Java » Jni Problem
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
16.05.2003, 16:30 Uhr
virtual
Sexiest Bit alive
(Operator)


Hallo,

ich habe einen C++ Wrapper geschrieben, in dem ich eine VM erzeuge und darin (man glaubt es kaum ) einige Javaklassen instanziiere. Die sache läuft recht rund, allerdings habe ich mit einer Sache schwere Probleme:
wenn ich jetzt die VM löschen will, so blockt das DestroyJavaVM uner Umständen. Meine Nachforschungen haben folgendes Bild ergeben:

1. Lt Manual blockert der Call deshalb, weil noch auf einige Threads gewartet wird.

2. Solche Threads scheinen dann implizit in der VM instanziiert zu werden, wenn man zB eine Swingklasse instanziiert (ohne diese jdoch weiter zu verwenden), dann blockt DestroyJavaVM, bei NonGUI elementen offenbar nicht.

Daher folgende Fragen:

1. Hatte schon mal jemand ein ähnliches Problem, wenn ja: wie schaut die Lösung aus?

2. Meine Vermutung ist, daß die Objekte, die ich erzeuge, ggf nicht korrekt abgeräumt werden. Die JNI Doku bezieht sich leider vornehmlich auf den Fall, wo JNI verwendet wird, um auf nativen code zuzugreifen, ich machs halt anders rum. Wie räumt man ein jobject ab? (Derzeit mach ich explizit ein DeleteGlobalRef und ein DeleteLocalRef, sollte doch ausreichend sein!?)

3. Angenommen, ich räume die Objekte zwar korrekt ab, aber der GC wird nicht explizit vom DestroyJavaVM angeworfen, wie mache ich das dann per Hand (sorry, doofe Frage, aber ich kenn mich halt in Java noch nicht so gut aus wie in C++ [da weiß ich es nämlich: garnicht ]). Irgendwie "System.GC()"?

Nachtrag: JDK 1.3.1_08, Windows und Sun

TIA
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
Dieser Post wurde am 16.05.2003 um 16:31 Uhr von virtual editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
17.05.2003, 16:13 Uhr
~0xdeadbeef
Gast


Soweit ich weiß, erzeugt der setVisible(true)-Call einen eigenen Thread, da bin ich grad aber nicht 100%ig sicher. Wie auch immer, du solltest mal versuchen, deine Hauptfenster per setVisible(false) und dispose() zu dichten. Zur Not kannst du immer noch den Holzhammer auspacken und System.exit(int) benutzen.

Den Garbage Collector kannst du über System.gc(); aufrufen. Gut geraten
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
17.05.2003, 16:58 Uhr
virtual
Sexiest Bit alive
(Operator)


Nee, ist nicht das Problem. Ein:

C++:
new bla = J*(); // * == Beliebige Swing Klasse

Genügt für das Desaster. Das Problem sind die AWT Threads, die allein beim instanziieren erzeugt werden. Es gibt derzeit - soweit ich das in einschlägigen NGs sehen konnte - keine triviale Lösung. Der Vorschlag, einfach ein System.exit abzusetzen (ein Vorschlag, den einige machen), ist nicht die lösung, weil das auch dei umgebende Application (aka mein C Programm) terminieren läßt.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
23.05.2003, 18:19 Uhr
~Ente_Knusprig
Gast


Wäre es nicht vielleicht eine Lösung wenn man den Teil der die VM startet als eigenen Prozess laufen lässt (als Prozess, nicht als Thread!). Ein System.exit() dürfte sich dann doch nur auf den die VM umschliessenden Prozess auswirken.

Versuchs evtl. auch mal mit java.lang.System.runFinalization() in der VM.
Bin zwar auch kein Java-Profi aber das könnte das sein was Du evtl. suchst.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
23.05.2003, 19:45 Uhr
virtual
Sexiest Bit alive
(Operator)


Nee, leider nicht. Das liegt daran, wie ich die VM einsetze: Ich schreibe eine Workflow Anwendung, in der bei jeder Aktivity eben ein Script ausgeführt wird. Wir haben da schon mit einer eigenen ScriptSpache und Anbindung an COM (Windows only) eigentlich ganz gute Integrationsmöglichkeiten, nun eben auch java- Die Scripte laufen nicht im Luftleeren Raum, sondern können mit Callbacks auf Daten im Prozess zugreifen. Wen ich jetzt meinen Prozess nochmal forke, dann müßte ich da noch jede Menge Synchronisationssch... machen.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ Java ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: