LuaJava - LuaWrapperBuilder vs Java2 Verifier

[Aaron Kamienski <aaronk@...>]

Hello,

I have run across a problem when trying to use LuaJava with Java2
(JDK 1.2.2 specifically).  The problem is that the Java code verifier
decides to barf on the code created when the LuaWrapperBuilder
ClassLoader loadClass() is invoked (i.e., when using the javaExport
LuaFunction).

The problem is in the buildCode() method.  It essentially generates
bytecode, that is something like the following, foreach method of 
the super-class or super-interface:

        if( lref == null )
        {
            super.thisMethod(someArguments);
            return;
        }
        else
        {
            ... // do actual work
        }

The problem is that, when the class that is being created is 
implementing an interface there is no super.thisMethod()!  The verifier 
is correct to catch this and complaining.  I suppose that a similar 
problem can be found when subclassing a class with abstract methods.

To get around the problem, I made the following changes to 
LuaWrapperBuilder.java:

183a184,185
> */
>         if (System.getProperty("lua.exportwrapper") != null) {
187c189
< */
---
>         }
444a447,449
>       Class decl_class = m.getDeclaringClass();
>       String decl_class_name = decl_class.getName().replace('.', '/');
>     if (!is_interface && !is_abstract) {
448,449d452
<     Class decl_class = m.getDeclaringClass();
<     String decl_class_name = decl_class.getName().replace('.', '/');
451a455,463
>       }
>       else {
>               // Msg is not completely correct... But should not be
encountered.
>               // I don't see how the Ref could be made null unless the 
>               // instantiation doesn't go right!
>               //       throw new LuaError("Lua implementation for
"+<java_type>+
>               //                        " does not implement method
"+<method_name>);
>               throwError(info, method_name);
>       }

The first change isn't necessary (it was just to enable the debugging
option of writing the class to a file).  The second bunch of changes
essentially check whether an interface is being implemented or an
abstract class extended; in which case an exception is thrown.  The
exception's msg isn't accurate, but I don't see how lref can become
null...

I'm sure that there is probably a better fix for this problem...
anyone?

thanks,

ajk
-- 
Aaron Kamienski <aaronk@snaptwo.com>
SNAP2 Corporation