[Kde-java] QtJava api via Dynamic Proxies progress - part 1

Mark Wielaard mark at klomp.org
Thu Aug 21 18:11:33 CEST 2003


Hi,

On Thu, 2003-08-21 at 15:58, Gert-Jan van der Heiden wrote:
> On Thursday 21 August 2003 14:46, Mark Wielaard wrote:
> The interface that should be proxilerized by Proxy is an protected inner 
> interface. That is the problem.

Thanks for the example. I now see where the problem is.
When an interface isn't public then defineclass.cc
(_Jv_ClassReader::checkExtends) checks that the implementing class has
the same loader as the interface and that it is in the same package.
The Proxy class isn't in the same package as the interface.
But since the (inner) interface is protected the check seems wrong.
Haven't come up with a fix yet though. But just disabling that check
makes the program work (even when compiled to native code, byte code
interpretation with gcj -C compiling and gij running worked already):

creating the _static_proxy instance in QFont static{}
SmokeInvocation()
QFont()
SmokeInvocation.invoke: public abstract void
qt.QFont$QFontProtectedInterface.newQFont()

> > Our current Proxy implementation actually generates byte code for the
> > Proxy class that is then read in with defineClass() and interpreted by
> > the interpreter. There are hooks in java.lang.reflect.Proxy to do some
> > magic to not need the interpreter which would make these kind of things
> > faster. But I don't know how much work it would be to implement that.
> 
> Would that improve performance everytime a method is called on a proxy, or 
> when the proxy is created?

It could (in theory) be used to setup the proxy class so you wouldn't
need to generate byte code for it and don't have to go through the
interpreter for every call. But I don't know if anybody has ever really
looked into doing it (and I don't know how much of a bottleneck this is
in practice anyway).

Cheers,

Mark



More information about the Kde-java mailing list