Proposal - move to JNA

[zafarella]

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

[nordfalk]

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?

[swrdfish]

@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]

Looks like you have made a lot of progress, @swrdfish .

[swrdfish]

@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.

[nordfalk]

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.

[swrdfish]

@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?

[nordfalk]

Yes, try to clone the jMagick interface, that will make porting current client code easy. Sorry for the lateral reply tor. d. 9. aug. 2018 07.03 skrev Binayak Ghosh <notifications@github.com>:

…

@nordfalk <https://github.com/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? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFx6Bb7TAoS7AbF6gdKsodk6csiBSheks5uO8KqgaJpZM4QrFE5> .

[judos]

@swrdfish i'm interested in your jna interface, did you get it working? As far as I can see only the Demo code exists, but you didn't adapt it for the whole api here in jmagick right? Also need it for a project.

[swrdfish]

@judos I never got it working properly, and no I did not adapt it for the whole api.

[hantsy]

The native access will protected in future, https://openjdk.org/jeps/472