[Qt-jambi-interest] Exceptions and crash after update to Qt Jambi 4.5.x

[Gregor Mückl]

On Monday 24 August 2009, Eskil Abrahamsen Blomfeldt wrote:
> Gregor Mückl wrote:
> > Caused by: java.lang.ClassNotFoundException:
> > eu.moonlight3d.ml3d.ui.mainwindow.view.Viewport$ProjectionType
> >         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> >         at java.security.AccessController.doPrivileged(Native Method)
> >         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> >         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> >         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> >         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> >         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> >         ... 16 more
> >
> > After that I get a VM crash. I find it strange that the
> > NoClassDefFoundError is thrown, although the class is definitely there
> > and must have been loaded. It must be noted, however, that the class in
> > question is loaded through a classloader that is created at runtime,
> > after Qt Jambi has been loaded and initialised through the default system
> > classloader.
> >
> > A further indication that this would be the case is that everything works
> > fine when I start the program from Eclipse, where the contents of the
> > plugins is (improperly) added to the system classpath at VM startup.
> >
> > So, could it be that the Jambi internals fail to query the correct class
> > definition because they are looking for it in the wrong classloader? If
> > so, is there a workaround for this? I need my own classloader to be able
> > to load plugins.
>
> The method in your stack trace is attempting to build a meta object for
> your class so that its functions and properties can be accessed from C++
> applications (e.g. in Qt Jambi Designer.) It will look in the class path
> for any class used in the signature of one of the methods. It should of
> course not crash if the classes cannot be resolved, this is a bug. I
> have made a task to fix this for the next patch release of Qt Jambi.
>
> Meanwhile, could you try annotating the methods that cause trouble with
> the "QtBlockedSlot" annotation, like this:
>
>
>     @QtBlockedSlot
>     void fooBar(ClassNotOnClassPath cnocp) {
>     }
>
>
> I don't know if this is an acceptable work-around to you, but it might
> avoid the function call which causes the exception, so it might be worth
> a try until the bug has been fixed.
>
> -- Eskil

Hi Eskil!

Thank you for this workaround. However, It only makes the other exceptions 
disappear, but not the one on Viewport$ProjectionType which causes the crash. 
I added the @QtBlockedSlot annotation to all methods in Viewport (the affected 
class) which contains the enum in its signature, but this does not seem to 
have any effect on this particular exception, I'm afraid. 

ProjectionType is actually an enum that only appears in the signature of a 
getter and a setter, following the conventions for Java properties. Could it 
be that (a) the runtime tries to map the getter and setter to a Qt property 
and because the type cannot be discoverd and (b) this is not prevented by the 
annotation because the issue is not about the discovery of slots in the class 
at all?

Seeing how Qt Jambi throws exceptions when there are undiscoverable classes 
and enums used in subclasses of QWidget (which happens a *lot* in my code), I 
would have to add that annotation in hundreds of places in the source code, 
which are tedious to find and debug. So I do not think that this workaround 
would be actually feasible as a short or medium term solution, even if we 
figure out a way to make it work. 

Maybe you should simply add an interface to Qt Jambi which allows registration 
of custom classloaders for use by the runtime for all of its reflection magic. 
This would nicely side-step the issues that we are discussing here. Custom 
classloaders are used quite commonly in complex Java projects (like OSGi based 
software).

Regards,
Gregor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt.nokia.com/pipermail/qt-jambi-interest/attachments/20090824/15ed729b/attachment.bin