Project

General

Profile

Support #6341

evaluate JNA as a replacement for LIBFFI and/or our built-in COM bridge

Added by Greg Shah about 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version:

History

#1 Updated by Greg Shah about 2 years ago

  • Subject changed from evaluate JNA as a replacement for LIBFFI to evaluate JNA as a replacement for LIBFFI and/or our built-in COM bridge

Java Native Access is an open source library which provides a dynamic mechanism to call native libraries directly from Java.

Where LIBFFI required a JNI interface to be created, JNA allows roughtly the same capabilities from pure Java. JNA embeds LIBFFI inside it (LIBFFI is MIT licensed, so that is OK) and uses it as the core backing the same what that FWD does.

In combination with the JNA Platform Library there are also facilities to integrate COM support without writing native code.

Using JNA could be a cleaner mechanism for native library support (see #1634) and/or for COM support (instead of our own COM bridge that we have in our JNI layer). One issue that would have to be handled is that JNA assumes that there is a static interface created for the given native interface. We would have to generate and reference this as part of the conversion. The current approach with LIBFFI does not require the same idea.

In both cases (LIBFFI and COM bridge), we would have to re-implement the layer and retest carefully. There is no functional benefit and it is not clear if there might be any performance benefit or penalty. We also don't know if there are any functional drawbacks that might cause issues.

Also available in: Atom PDF