New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jnaerator seems to generate invalid stubs for the callback / library under the following code: #282

johnny-tc opened this Issue Mar 8, 2012 · 2 comments


None yet
2 participants

johnny-tc commented Mar 8, 2012

Actual Behavior:
JNAerator takes the following when running the jnlp (or the jar directly)

void __stdcall hello();
typedef void ( __stdcall *func)(int);

and generates:

package test;
import com.ochafik.lang.jnaerator.runtime.LibraryExtractor;
import com.ochafik.lang.jnaerator.runtime.MangledFunctionMapper;
import com.ochafik.lang.jnaerator.runtime.Mangling;
import com.sun.jna.Callback;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.NativeLibrary;

  • JNA Wrapper for library test
  • This file was autogenerated by JNAerator,
  • a tool written by Olivier Chafik that uses a few opensource projects..
  • For help, please visit NativeLibs4Java , Rococoa, or JNA.
    public interface TestLibrary extends Library {
    public static final String JNA_LIBRARY_NAME = LibraryExtractor.getLibraryPath("test", true, TestLibrary.class);
    public static final NativeLibrary JNA_NATIVE_LIB = NativeLibrary.getInstance(TestLibrary.JNA_LIBRARY_NAME, MangledFunctionMapper.DEFAULT_OPTIONS);
    public static final TestLibrary INSTANCE = (TestLibrary)Native.loadLibrary(TestLibrary.JNA_LIBRARY_NAME, TestLibrary.class, MangledFunctionMapper.DEFAULT_OPTIONS);
    public interface func extends Callback {
    void apply(int int1);
    • Original signature : __stdcall void hello()
    • native declaration : line 2
      @mangling({"_Z5hellov", "?hello@@YAXXZ"})
      void hello();

Expected Behavior:
The interface func should probably extend StdCallLibrary.StdCallCallback and the library itself should extend StdCallLibrary.

MSDN says this (in practice, the compiler seems to lenient with respect to the order of the return type and the extension so my hope is jnaerator would be as lenient or at least take the standard syntax):

The impact would probably mean some really odd behavior when the stack is unwound when the callback is utilized or when the direct call is performed.
Reversing the order of the function prototype, __stdcall void hello() seems to extends the StdCallLibrary, but reversing it in the typedef does not help.


This comment has been minimized.


ochafik commented Mar 10, 2012

Hi @johnny-tc ,

Thanks for your report !

This is now fixed in the latest snapshot.


@ochafik ochafik closed this Mar 10, 2012


This comment has been minimized.

johnny-tc commented Mar 20, 2012

Thanks, it works for me now on the JNAerator runtime (based on JNA); when I use the BridJ runtime, which seems to be the default moving forward?, I get the following errors for the following input:

int __stdcall foo();

  1. ERROR in file:\test\ (at line 20)
    @convention<Convention.Style.StdCall >
    Syntax error on token(s), misplaced construct(s)

  2. ERROR in file:\test\ (at line 20)
    @convention<Convention.Style.StdCall >
    The annotation @convention must define the attribute value

  3. ERROR in file:\test\ (at line 20)
    @convention<Convention.Style.StdCall >
    Syntax error on token ".", extends expected

    3 problems (3 errors)INPUTS = {file:///test/
    package test;
    import org.bridj.BridJ;
    import org.bridj.CRuntime;
    import org.bridj.ann.Convention.Style;
    import org.bridj.ann.Convention;
    import org.bridj.ann.Library;
    import org.bridj.ann.Runtime;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment