 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
12 messages in net.java.dev.jna.usersRe: [jna-users] Requiring Library sup...| From | Sent On | Attachments |
|---|---|---|
| Charles Oliver Nutter | Sep 4, 2007 8:36 am | |
| Timothy Wall | Sep 4, 2007 9:01 am | |
| Charles Oliver Nutter | Sep 4, 2007 9:50 am | |
| Timothy Wall | Sep 4, 2007 10:29 am | |
| Charles Oliver Nutter | Sep 4, 2007 12:59 pm | |
| Wayne Meissner | Sep 4, 2007 7:13 pm | |
| Philip Jenvey | Sep 4, 2007 9:38 pm | |
| Wayne Meissner | Sep 4, 2007 10:01 pm | |
| Charles Oliver Nutter | Sep 4, 2007 10:40 pm | |
| Wayne Meissner | Sep 4, 2007 11:41 pm | |
| Charles Oliver Nutter | Sep 5, 2007 12:04 am | |
| Timothy Wall | Sep 5, 2007 5:45 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [jna-users] Requiring Library superinterface? | Actions... |
|---|---|---|
| From: | Charles Oliver Nutter (char...@sun.com) | |
| Date: | Sep 4, 2007 9:50:38 am | |
| List: | net.java.dev.jna.users | |
Timothy Wall wrote:
On Sep 4, 2007, at 11:36 AM, Charles Oliver Nutter wrote:
Why is it that native library definition interfaces must derive from com.sun.jna.Library?
In JRuby, we'd like to have the option of compiling/running without JNA, and that generally means being able to avoid all static references to JNA classes. I can use reflection to load up com.sun.jna.Native and loadLibrary that way, but I eventually have to have a real interface to use. Because that interface must derive from Library, I'm sunk if JNA isn't present.
Would it be possible to eliminate this requirement? The eventual library returned could still implement Library, but requiring me to extend it seems a bit of a problem.
Since you're explicitly passing the interface class to Native.loadLibrary, you're implicitly identifying it as a native library interface, so the Library interface is redundant.
You can't instantiate your own proxy due to Library.Handler having default access. Even if it were public, you don't have access to is Native.loadLibrary's maintenance of type mapper and structure alignment options. The getTypeMapper and getStructureAlignment methods assume any mapped interface stores those options, which are required by Structure and CallbackReference, since those classes have no other way of properly determining their context without forcing the user to explicitly define it.
If you're dynamically generating an interface, though, isn't it trivial to just throw Library into the mix?
This isn't a dynamically-generated interface; it's a real static interface. Basically, when doing this:
POSIX posix = (POSIX)Native.loadLibrary("c", POSIX.class);
I want my POSIX interface to not extend com.sun.jna.Library. It's just a plain old interface; whatever logic loadLibrary is doing to create a native library wrapper should be able to add in the Library interface to that resulting type.
If I omit "extends Library" from my POSIX interface, I get the following error:
java.lang.IllegalArgumentException: Not a valid native library interface: interface org.jruby.ext.POSIX
- Charlie