通过命令行调用与通过JNI调用的区别

3
我需要从Java应用程序服务器中调用Tesseract OCR(它是一个开源的C++库,可进行光学字符识别)。目前,使用Runtime.exec()运行可执行文件非常容易。基本逻辑如下:
1.将当前保存在内存中的图像保存到文件中(.tif格式); 2.将图像文件名传递给tesseract命令行程序; 3.使用FileReader从Java中读取输出文本文件。
通过为Tesseract编写JNI包装器,我可能会获得多少性能提升?不幸的是,在Linux上没有可用的开源JNI包装器。我必须自己来完成,并且想知道是否值得开发成本。

1
请问您能否粘贴一下在Runtime.exec()中使用的命令来运行tesseract命令?我无法弄清楚... - jorgen
3个回答

4

很难说这是否值得。如果您假设通过JNI在进程内完成,OCR代码可以直接访问图像数据而无需将其写入文件,则肯定可以消除任何磁盘I/O限制。

我建议采用更简单的方法,只有在性能不可接受时才选择JNI选项。至少那样您将能够进行一些基准测试并估计可能能够实现的性能增益。


4

如果您想自己编写包装器,我建议您查看JNA。它可以让您仅使用Java代码调用大多数“本地”库,并为您提供比原始JNI更多的帮助以确保安全性。 JNA适用于大多数平台。


谢谢你的建议,我之前没有听说过JNA。如果将来有需要进行本地绑定的项目,我会研究一下它。 - Ish
这里提到了另外两个映射库(JInvoke和Swig):http://stackoverflow.com/questions/1172486/is-there-a-market-for-jni - dma_k
1
JNA与C++不兼容,而是与C兼容。Tesseract已经(大部分)迁移到了C ++。 - Hovercraft Full Of Eels
@Hovercraft - 这是一个我没有考虑到的很好的观点。JNA非常方便,但并不适用于每个应用程序。 - erickson

1
我同意tweakt的观点。如果没有性能原因,请勿使用JNI。如果您在JNI层或OCR本身中存在内存泄漏或崩溃的可能性,则应用程序的稳定性也可能会受到影响。如果通过命令行界面使用它,这种情况永远不会发生(所有内存将在程序退出时释放,并且可以在调用者代码中检查所有异常程序终止)。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接