This is obviously unexpected and incorrect, yet cannot be fixed by just adding more data on the C side: you'd have to remember the callback object at the very least, which you could in the user_data
field, but you'd have to make it a global reference. Yet, there would be no easy way to later correctly delete that global reference, since to unset the pollfdNotifiers you just pass NULL to the
same function again, and you don't get back any data on what was there before.
The easiest way to fix this was thus to change to a HashMap, Concurrent since access can be from random threads.
The key was chosen to be the Context.hashCode(), as Integer lookup and comparison is fast, and the hashCode depends directly on the contextPointer stored in the Context (which identifies it).
This works for sure on 32bit systems, but I'm still concerned about 64bit systems, where a long would probably make more sense, I need to think about it some more.
Everything is done in Java here as it's much easier and cleaner, since those are only convenience functions/structs.
Byte order conversion is conveniently handled by ByteBuffer too, and using slice() we access the same memory all around.
Added some final keywords to LibUsb and BufferUtils.
Only fill_control/get_control is still outstanding.
getDescriptor() and getStringDescriptor() were removed from native JNI, since they are static inline convenience functions in libusb.h and don't do anything more than calling the appropriate real function.
To support FREE_TRANSFER in the case the user doesn't set (or explicitely sets) a callback of null on the Java side, a small C-callback was created that just takes care of cleaning up the Java objects and resources.
Add methodID field to transfer_data structure, so that it can be cached at set() time and the callback is faster.
Also update the length when setting a new buffer!
Check all variable names for consistency.
Fix memory leak on failed getDeviceDescriptor.
Use result == LIBUSB_SUCCESS instead of just !result, it is much clearer what the integer that you get as result actually means that way.
Move callback and maxNumIsoPacketSize to C, minimizing what is kept in Java: only the pointer and the transferBuffer. setLength() is still checked here, as that's easiest.
Update the tests to match the changes and add documentation on the new methods.
*.java: Fix code and comment formatting to be equal everywhere and conform to what I could see as being the
expected usb4java standard.
*.java: Remove Apache-Commons dependency for extremely simple HashCode/Equals involving only the pointer
variable, instead use the Eclipse-generated methods.
calls return without throwing exceptions.
DescriptorUtils.java: update to use the correct masks and variables, always return "Unknown" on a not-handled
value.
*Descriptor.java: update equals/hashcode to use all fields in the same order as they are defined (makes
checking this much easier in the future!). For example bRefresh was missing or some extra/extraLength checks.
InterfaceDescriptor: there is no need for a dump(DeviceHandle) here, so removed it and updated the call in
Interface.java.
since you don't know if the refcount reached zero and it was deallocated. Every new reference means the
refcount gets increased AND a new reference indeed exits, so this always works, unless you let references go
out of scope or overwrite them, which is clearly incorrect in any case.
Also add missing checks for setDeviceHandle() in Transfer.
Right now for example, getting a new config descriptor re-using an old ConfigDescriptor object just overwrites the old pointer, without freeing it or telling the user, resulting in a memory leak.
This way, the user gets notified when he's re-using an object that he hasn't cleaned up yet, and he can react and call the appropriate free/cleanup function.
Add missing NOT_NULL checks.
Simplify getPortPath() ifdef.
Check for result value in libusb_init and only setContext if the call succeeded.
Use always same style of NULL checks in usb4java.h.
Also, I don't see why there is any need to deviate from using a pointer to using a ByteBuffer here, it will not make memory management automatic, and just makes the DeviceDescriptor "different" for no apparent reason. So changed back to pointer.
Change DIRECT_BUFFER to not call the isDirect() method (expensive!), but instead to check the return value of getDirectBufferAddress, which is always used anyway.
It also detects cases where the JVM doesn't support direct buffers and other error conditions this way.
I agree with this on set*() calls, but I argue that it is more correct to return the appropriate, smaller type on get*() calls, the same as with the other classes: the values you can read are of appropriate, original size.
In C you need to have a length parameter to know how much you can write, here we can always just get the maximum, which is quite small, and then append to the StringBuffer, which will take care of any length management.
Also fix init/exit to not handle the default context in any special way: the default context is reference counted, and it is thus NOT an error to call init on it multiple times, or exit for that matter afterwards.
