Skip to content

FromNativeContext using java.lang.reflect.Type instead of java.lang.Class #310

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

Closed
marco2357 opened this issue Mar 24, 2014 · 2 comments
Closed

Comments

@marco2357
Copy link
Contributor

Dummy example:

class Pointer<T> implements NativeMapped {
    public Object fromNative(Object nativeValue, FromNativeContext context) {
       // context.getTargetType() -> Pointer.class
    }
}

Sometimes it would be useful to know the full generic information. E.g. whether a Pointer<Integer>, a Pointer<Double> or a Pointer<Pointer<Pointer<Short>>> needs to be created.

This would be easy to implement; in the Native class, just give method.getGenericReturnType() to registerMethod() instead of method.getReturnType(), adapt fromNative() to take a Type and change the C code.
Though this would change the API and requires Java 1.5. So maybe instead of changing the API an addition would be better.

@twall
Copy link
Contributor

twall commented Mar 25, 2014

Where do you envision doing this extra transformation? do you have an example?

On Mar 24, 2014, at 9:14 AM, marco2357 notifications@github.com wrote:

Dummy example:

class Pointer implements NativeMapped {
public Object fromNative(Object nativeValue, FromNativeContext context) {
// context.getTargetType() -> Pointer.class
}
}

Sometimes it would be useful to know the full generic information. E.g. whether a Pointer, a Pointer or a Pointer<Pointer<Pointer>> needs to be created.

This would be easy to implement; in the Native class, just give method.getGenericReturnType() to registerMethod() instead of method.getReturnType(), adapt fromNative() to take a Type and change the C code.
Though this would change the API and requires Java 1.5. So maybe instead of changing the API an addition would be better.


Reply to this email directly or view it on GitHub.

@marco2357
Copy link
Contributor Author

Do you mean where/how I could make use of this extended information? If FromNativeContext.getTargetType() would return a Type instance (instead of Class), I could do something like:

class Pointer<T> implements NativeMapped {
    private Memory m;

    private Pointer(ParameterizedType type) {
        Type elementType = t.getActualTypeArguments()[0];
        if(elementType == Short.class) {
            m = new Memory(2);
        } else if(elementType == Integer.class) {
            m = new Memory(4);
        }
        // ...
    }

    public Object fromNative(Object nativeValue, FromNativeContext context) {
        return new Pointer((ParameterizedType)context.getTargetType());
    }
}

But I now decided to write little wrappers around native methods taking care of such conversions. This works right now, should execute faster and the JNA TODO file says anyway "eliminate type conversion contexts". So this seems the best thing to do.

Thanks!
Marco

mstyura pushed a commit to mstyura/jna that referenced this issue Sep 9, 2024
…#310)


Motivation:

We the build failed we should ensure we also include hs_err* files as it may have failed due a native crash

Modifications:

Adjust path matching to include hs_err as well

Result:

Easier to debug native crashes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants