Proposal - move to JNA
Opened this issue · 9 comments
As an alternative to existing calls, following could be used to make call to native libs https://github.com/java-native-access/jna
This will address many versioning limitation and should avoid many memory leek issues, but will keep the "DSL" as is.
Open to discussion/suggestions. Just a thought. Feel free to add your opinion/experience
Its a fine idea - I'm not against it.
... but it would require a major rewrite (and I'm not taking part of that rewrite).
Any volunteers?
@nordfalk I would like to volunteer. I was trying to wrap imagemagick with JNA for a project, and I am thinking of contributing. But I need some help as I am pretty new to JNA and I am stuck at some basic stuff (I am getting segmentation fault while trying to retrieve the Image struct). I have hosted the code here: https://github.com/swrdfish/dumbledore
Can anyone point me to some documentation or give some suggestions to resolve such problems?
@nordfalk yes I got it working on linux! I am now struggling with windows dlls, my company needs this on windows, so I am working on that.. I will work on the linux version once I get all the windows related issues fixed.
Congratulations, @swrdfish !
Looking at https://github.com/swrdfish/dumbledore/blob/master/src/main/java/com/swrdfish/tools/dumbledore/Demo.java my impression is that those that are currently using jMagick will need to rewrite their client code - would it be possible possible to minimize how much the client code would need to be rewritten?
Perhaps by using some Java wrapper classes that invoke your JNA layer.
@nordfalk yes using jMagick is much simpler that using direct JNA bindings. So having a wrapper will definitely help. Also the current version has a lot of small memory issues. So we need tests to cover atleast the core functionality.
I am not sure what the API should look like, maybe I can try to clone the jMagick interface, that will make porting current client code easy. Any suggestions?