[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-java
Subject:    Re: [Kde-java] Qt bindings hang with gcj
From:       Thomas Kuhn <t_kuhn () gmx ! de>
Date:       2001-08-23 21:17:22
[Download RAW message or body]

Am Donnerstag, 23. August 2001 20:02 schrieb Richard Dale:

> > That was one of the first things I did, but it didn't help. I rewrote
> > parts of JavaSlot  and QtSupport to use CNI. and removed
> > QtSupport:GetEnv() completly. Now it's working fine with gcj. Later I had
> > to add 2 static methods and a hashtable to Invocation.java - gcj seems to
> > have some problems with java objects that are created with the new
> > operator from c++, so I added a factory that creates and deletes them for
> > me.
>
> Are you sure that this new hash table doesn't duplicate the functionality
> of these tables?
>
>  	qtKeyToJavaMap = new WeakValueMap();
> 	qtSignalDictionary = new HashMap();
> 	qtSlotDictionary = new HashMap();

Mmh the only purpose of the new Hashmap is to keep one reference to the 
created Invocation object visible to the garbage collector so it won't get 
deleted too early. There is nothing like JvGlobalRef aviable when you use cni.

I had to change the constructor of JavaSlot.cpp to :
   invocation = org::kde::qt::Invocation::createNewInvocation(receiver, slot);

This way the Invocation object is created in a java function and that works 
fine with gcj. The second function I added to Invocation.java is 
deleteInvocation which removes the Invocation object from the hashmap.


> > The modified qt bindings are
> > currenty working fine with gcj here, so I think there are some bugs with
> > GetJavaVM etc. in the jni interface. Now I'll write a makefile and put
> > the gcj files (only four and about six header files, most were generated
> > with gcjh) in a seperate directory because they compile only with gcj. If
> > you are interested I'll mail you the changes I've made. Pherhaps we could
> > put up a configure script that let anyone choose whether to build for
> > generic java or for gcj using cni for the callback parts.
>
> Yes, that sounds a good idea - nearly all the library is the same for gcj
> and ordinary java. I hadn't thought about this at all, so it has come as a
> nice surprise out of the blue :-). I'd be very interested in any sizing
> statistics, like start up time and memory occupancy for gcj java vs.
> standard interpreted java.
Yes, the two new methods in ivocation don't hurt the 'ordinary' java part 
(and they are only three lines each) so the only two files that need to be 
different are QtSupport.cpp and JavaSlot.cpp. 

Greeting - Thomas
_______________________________________________
Kde-java mailing list
Kde-java@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-java

[prev in list] [next in list] [prev in thread] [next in thread]