java-native-access / java-native-access/jna
Debug logging
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 8.9k
- Forks
- 1.7k
- PR merge metrics
- No merged PRs in 30d
Description
JNA 4.1.0.
Arm / Debian 7.8
I have two near-identical devices running a java web service app that involves JNA at a couple of points. On one device, everything was working just fine. On the other device, it couldn't load my library. Software versions were the same, directory and file permissions were the same, user groups were the same, but it wouldn't load.
I turned on debugging (using Wildfly java app server) and it showed that it was trying the exact, correct absolute file path. It showed no fail messages and just continued on to trying other paths.
I got maven to download the JNA sources and stepped through it in my Netbeans debugger and I found that line 171 of NativeLibrary.java (loadLibrary() method), where it tries to open the lib file, was triggering the exception in the catch on 173. The exception showed a glibc version conflict (the working device had a newer version than the device that didn't work), but it looks like JNA just eats that continues to try other paths.
It would have been really really helpful if JNA could have written the exception description to the log right at that point (line 174). It would have saved me many hours of hair pulling trying to figure out what was different between my app and file/directory permissions on the two different devices! Silently catching the exception made me think the problem was something else entirely from what it actually was.
I use JNI and JNA both (for different reasons, where differences in speeds on the order of less than a millisecond either matter or don't), and I really appreciate how much easier JNA makes things!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in NativeLibrary.java at the loadLibrary() method around lines 171-174, where the issue reports that an exception is caught while opening the library. Review the existing debug logging there and determine how the exception description should be surfaced. Done means the failed load attempt records the underlying exception instead of proceeding silently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- operating-systems
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100