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

[Gert-Jan van der Heiden]

On Thursday 21 August 2003 14:46, Mark Wielaard wrote:
> Hi [CCed to gcj developers mailinglist - from kde java bindings
> mailinglist, discussion about QT java bindings trhough Proxy classes],
> > So it still allowed the public interface method to be implemented by a
> > protected method, if you didn't need to change the actual implemention.
> > Because QFontProtectedInterface  is only internal it wouldn't matter if
> > it had to be public.
> >
> > > This familiar output appeared:
> > >
> > > $ ./doit
> > > SmokeInvocation()
> > > SmokeInvocation(obj)
> > > SmokeInvocation.invoke: public abstract void
> > > qt.QFont$QFontProtectedInterface.newQFont()
> > > SmokeInvocation.invoke: public abstract void
> > > qt.QFont$QFontPublicInterface.setPointSize(int)
> > > SmokeInvocation.invoke: public abstract java.lang.String
> > > qt.QFont$QFontPublicInterface.substitute(java.lang.String)
> > >
> > >
> > > Though my compiler isn't a official release, I 3.3 is released in may,
> > > and early this month (8 aug) 3.3.1 is released.
> >
> I tried to see what goes wrong with the libgcj Proxy implementation, but
> I am not to familiar with this code and couldn't immediately find it. If
> you have a small example (that doesn't need the QT library) that would
> help.

I attatched a small example (It's only 953 bytes, I hope that's no problem for 
the mailinglists). I stripped a lot of code, it compiles without external 
libs. It consists of 3 Java files now: Doit.java (main method), QFont.java 
(creates the proxy), SmokeInvocation.java (implements  InvocationHandler). 

./compile.sh compiles the code.

I've added some comment in QFont.java to indicate which interface needs to be 
public.  The error in the main method in Doit.java occurs in the second line:

QFont myFont = new QFont();

The failing invocation of Proxy.newProxyInstance() is in the static{} 
declaration of QFont.

The interface that should be proxilerized by Proxy is an protected inner 
interface. That is the problem.


> 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? 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcj_proxy.tar.gz
Type: application/x-tgz
Size: 953 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-java/attachments/20030821/0270e8e6/gcj_proxy.tar.bin