[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:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2001-08-24 3:40:06
[Download RAW message or body]

On Thu, 23 Aug 2001, Thomas Kuhn wrote:
> 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 see, it just replaces this code in the JavaSlot constructor and destructor,
which uses the JNI  NewGlobalRef() and DeleteGlobalRef() f'ns:

JavaSlot::JavaSlot(jobject receiver, jstring slot)
{
	...
	javaInvocation = env->NewObject(invocationClass, cid, receiver, slot);
	invocation = env->NewGlobalRef(javaInvocation);
}

JavaSlot::~JavaSlot()
{
	JNIEnv *	env;
	env = QtSupport::GetEnv();
	env->DeleteGlobalRef(invocation);
}

-- Richard

> 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
_______________________________________________
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]