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

[Eskil Abrahamsen Blomfeldt]

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