Running native code using JNI from within java always imposes additional risks. The JVM is no longer sandboxed, so there might be some security issues. In addition, there could be errors like memory leaks or memory corruption within the JNI-layer (JMagick) or within the native code (ImageMagick).
This is especially dangerous for long running processes (typically web-application-servers). Memory corruption or a segmentation fault (maybe triggered by a intentionally manipulated image) might bring down the whole server.
On the other side, in reality the situation is not as bad as it sounds above. JMagick is well tested, and for standard use-cases it prooves to be very stable.
Some additional information is available on the JMagick-users mailing list where this topic has been discussed to some detail.
convert
command, but the one supplied by Microsoft. What can I do?
Read the Developer's Guide, section Setting up the Environment.
-foo
, but im4java
does not. Why? And what can I do about it?
Keeping up with actively devolped tools is not easy, im4java will always lag behind in the support of new commandline options. But adding support for a new option is straightforward:
input/XXXinterface.txt
and
add your new option. The syntax of the file should be
clear.
make src jar
. That's it!input/XXXinterface.txt
on the jmagick-users mailing-list. I will add it to the
next version of im4java.
CommandException
. What can I do?
In case there is a CommandException, you should always print the associated error-text:
The error-text ist the stderr of the used command. Hopefully it tells you why it failed.
To be answered.