[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-23 17:57:05
[Download RAW message or body]

On Thu, 23 Aug 2001, Thomas Kuhn wrote:
> Am Donnerstag, 23. August 2001 12:52 schrieb Richard Dale:
> > > qtjava.java:
> > >
> > > 	static {
> > > 		System.loadLibrary("qtjava");
> > > 		qtjava.registerJVM();
> > > 		qtjava.setJavaSlotFactory();
> > > 		qtKeyToJavaMap = new WeakValueMap();
> > > 		qtSignalDictionary = new HashMap();
> > > 		qtSlotDictionary = new HashMap();
> > >
> > > 	}
> > >
> > > The JavaSlot.h/cpp code also calls Invocation.java to invoke a slot.
> >
> > Further to this, you could try caching the current JNIEnv in '_env' in
> > registerJVM(), as well as the jvm pointer.
> >
> > static JNIEnv *	_env;
> >
> > ...
> >
> > void
> > QtSupport::registerJVM(JNIEnv * env)
> > {
> > 	jstring	testString;
> > 	const jchar * _jchar_str;
> >
> > 	env->GetJavaVM((JavaVM **) &_jvm);
> > 	_env = env;
> > 	...
> >
> > And then change QtSupport::GetEnv() to return the _env variable:
> >
> > JNIEnv *
> > QtSupport::GetEnv()
> > {
> > 	return _env;
> > }
> 
> 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();

This method in qtjava.java is responsible for maintaining the association
between C++ instances and their corresponding java instances, allocating the
java instance if an association for that C++ instance doesn't already exist:

 	public static Object objectForQtKey(long qt, String className,
boolean allocatedInJavaWorld);

> 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.

> I'll change the kdebindings as well 
Yes, great - the only files which depend on Invocation.java are
KDEJavaSlot.h/.cpp.

> in the next days to work with gcj and try to write a configure script that 
> can to that (I'm not too experienced with that automake/autoconf stuff :-)) 
OK - I keep trying with autoconf too, but don't seem to get anywhere :). Perhaps
we can get some KDE autoconf experts to help out with finishing it off.

> ). Anyway, I think there will be much interest in a qt that is usable with 
> gcj.
Yes, I agree!

> > Whether or not this fixes the problem would depend on what bug there is in
> > gcj - it could be that just GetJavaVM() is broken and everything else is
> > ok. Or not...
> Well I think if a native method is invoked from java everything is ok, the 
> other way makes IMHO trouble with jni. 
Oh well...

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