search

techblue / jmagick

GNU Lesser General Public License v2.1
187 stars 83 forks source link

Proposal - move to JNA #40

Open zafarella opened 6 years ago

zafarella commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

swrdfish commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 https://github.com/techblue/jmagick/issues/40#issuecomment-411637573, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFx6Bb7TAoS7AbF6gdKsodk6csiBSheks5uO8KqgaJpZM4QrFE5 .

judos commented 3 years ago

@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 commented 3 years ago

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