Skip to content
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

Direct interface primitive vs class #918

Closed
Ortner opened this issue Feb 2, 2018 · 0 comments
Closed

Direct interface primitive vs class #918

Ortner opened this issue Feb 2, 2018 · 0 comments

Comments

@Ortner
Copy link

Ortner commented Feb 2, 2018

JNA-Version: 4.5.1
JVM: Oracle 1.8.0_111
Operating System: macOS High Sierra 10.13.3

I have a simple C-Function, that is mapped to Java using direct mapping. The C-Function is defined as:

double JOSim_Base_Test_add(double a, double b);

The working (direct) mapping of this function would be:

    static {
        try {
            Native.register("JOSimBaseLib");
        }catch(Exception e) {
            e.printStackTrace();
        }
    }
    
    //function prototype
    public static native double JOSim_Base_Test_add(double p0, double p1);

But it is also possible to declare the native function in Java with Double:

    static {
        try {
            Native.register("JOSimBaseLib");
        }catch(Exception e) {
            e.printStackTrace();
        }
    }
    
    //function prototype with Double.class
    public static native Double JOSim_Base_Test_add(Double p0, Double p1);

The registration of the method does actually work. It doesn't throw a UnsatisfiedLinkException. The Methods c-peer is found in Native.register(Class<?> cls, NativeLibrary lib) and also put on the registeredClasses map - even though the prototype is incorrect.

Finally, when calling the native method in Java, a NullPointerException is thrown.

Issue

When using direct mapping the register method should throw an UnsatisfiedLinkException, if the native function doesn't match the prototype of the declared function.

matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Feb 4, 2018
For direct mapped methods the java value is directly passed to the C
side. For wrappers this means, that the object pointer is passed and
not the primitive values.

This changeset removes the mappings for the Wrapper classes and makes
it possible to use a type converter to make the call possible, at the
cost of higher calling costs.

Closes: java-native-access#918
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant