用Java重写C代码还是使用JNI？
我目前正在开发一个用Java编写的项目。我们有一堆用C/C++编写的算法(至少有几百种)需要合并到我们的项目中。我们的两个选择是使用JNI调用此代码，或者重写Java中的所有算法。
我知道使用JNI的后果，它可能会带来一系列全新的问题，这就是为什么用Java重写所有代码都被考虑的原因。但是重写它的想法是seems...wrong。据我所知，这些算法已经过测试和工作，它们只是使用了错误的语言。
在这种情况下，JNI会让这项任务变得简单吗？或者它会比用Java重写代码更让人头疼吗？
编辑#1:相关问题- Usefulness of JNI
Java #2:Java我们的项目并不意味着以任何方式都是可移植的。这可能会消除JNI的一个缺点，因为它可能会降低可移植性。
回答 11
Stack Overflow用户
发布于 2009-03-04 18:51:15
简单的答案是，如果代码要被调用很多，而且性能很重要，那么就把它转换成Java。
更复杂的答案是：
- 如果库很容易包装在JNI中，那么就使用JNI
- 如果您的测试针对的是C/C++代码很容易转换成Java，那么就使用
我会做以下事情：
- 采用其中一个算法，并将其封装在JNI
- 中，采用相同的算法并将其转换为Java
- ，看看做
- 哪个更痛苦如果速度很重要，然后分析两个版本，看看哪一个是可接受的。
<代码>F215
Stack Overflow用户
发布于 2009-03-04 16:22:53
我认为答案在于调用的java代码和调用的C/C++代码之间的耦合度，以及重写所需的工作量。如果您的C代码接受几个整数，执行一些繁琐的计算，并返回另一个int。使用JNI。如果有许多复杂的来回，但算法相当简单，重写它们。故障线路是JNI连接。如果这将是复杂的，你可能最终编写更多的JNI接口代码，而不是重写的算法代码。
Stack Overflow用户
发布于 2009-03-04 16:22:04
如果“算法”被很好地打包，也许可以通过JNI创建一些自动粘合代码？这将降低出错的风险(手动创建数百个单独的组件听起来很危险)，并使成本与要添加的算法数量无关。
重写数百个组件听起来非常危险，我绝对建议至少先更仔细地研究JNI。
相对于项目的其余部分，算法有哪些I/O要求？如果它们是相当松散耦合的，也许可以将它们作为独立的程序运行，作为子进程从Java调用，并使用例如stdio来共享数据？
https://stackoverflow.com/questions/611296
复制相似问题