blocks|key|3338387|text|如果“算法”被很好地打包，也许可以通过JNI创建一些自动粘合代码？这将降低出错的风险(手动创建数百个单独的组件听起来很危险)，并使成本与要添加的算法数量无关。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338388|重写数百个组件听起来非常危险，我绝对建议至少先更仔细地研究JNI。|3338389|相对于项目的其余部分，算法有哪些I/O要求？如果它们是相当松散耦合的，也许可以将它们作为独立的程序运行，作为子进程从Java调用，并使用例如stdio来共享数据？|3338390|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If the "algorithms" are well-packaged, perhaps it's possible to create some automatic glue code, through JNI? That would cut down on the risk of errors (creating hundreds of individual components manually sounds risky), and make the cost independent of the number of algorithms to add, more or less.

Rewriting hundreds of components sounds very risky, I would definitely recommend at least investigating JNI more closely first.

What I/O requirements do the algorithms have with respect to the rest of the project? If they are fairly loosely coupled, perhaps it'd be possible to run them as free-standing separate programs, invoked as sub-processes from Java and using e.g. stdio to share data?

blocks|key|346414|text|我认为答案在于调用的java代码和调用的C/C%2B%2B代码之间的耦合度，以及重写所需的工作量。如果您的C代码接受几个整数，执行一些繁琐的计算，并返回另一个int。使用JNI。如果有许多复杂的来回，但算法相当简单，重写它们。故障线路是JNI连接。如果这将是复杂的，你可能最终编写更多的JNI接口代码，而不是重写的算法代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346415|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think the answer lies in the amount of coupling there would be between the calling java code and the invoked C/C++ code and in the level of effort the rewrite would entail. If your C code takes a few integers, does some hairy calculation, and returns another int. Use JNI. If there's a lot of complex back and forth, but the algorithms are reasonably simple, rewrite 'em. The fault line is the JNI connection. If that's going to be complex, you may end up writing more JNI interface code than you would algorithm code for a rewrite.

blocks|key|3125499|text|我仍然会认真考虑使用JNI，特别是如果您能够最大限度地减少跨语言接口的数量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3125500|例如，如果有一整堆C函数都有相同的输入和输出，但只是在输入上做不同的工作，那么就用一个额外的参数将其包装在一个JNI包装器中，以指定要使用的特定算法。|3125501|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'd still seriously consider going for JNI, particularly if you're able to minimize the number of cross-language interfaces.

If, for example, there's a whole stack of C functions that all have the same inputs and outputs, but just do different work on the inputs, wrap that up in a single JNI wrapper with an additional parameter to specify which specific algorithm to use.

blocks|key|3338451|text|试一试JNI。然后，如果遇到任何问题，您可以重写有问题的问题，或者用webservices包装JNI调用，并将它们部署到不同的机器或虚拟机器上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3338452|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Give JNI a try. Then if faced with any problems you may rewrite the problematic ones or wrap JNI calls with webservices and deploy them on different boxes or virtual boxes.

blocks|key|347890|text|如果您计划用Java编写未来的项目，而不是C/C%2B%2B。我现在就咬紧牙关，把代码移植到java上。你等待的时间越长，情况就会变得越糟。在这种情况下，JNI听起来很吸引人，但是当其他人都在进行有趣的新C%2B%2B项目时，您就会遇到一个问题，那就是有人不得不维护Java代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|347891|如果这是一个一次性的Java项目，那么为什么要用Java编写它呢？|347892|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you plan to write future projects in Java, as opposed to C/C++. I would bite the bullet now, and port the code over to java. The longer you wait the worse it will become. The JNI sounds attractive in this case, but then you will have the problem of somebody having to maintain the C++ code when everyone else is on the fun new Java projects.

If this is a one time Java project, then why are you writing it in Java?

blocks|key|351386|text|如果这是纯Windows的，并且它们已经在DLL中，那么也许JNA会有用。(如果通过JNA进行函数调用的性能影响不是很大)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|351387|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/twall/jna/#getting_started^0|U|3|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

If this is Windows-only, and they're already in a DLL, perhaps <a href="https://github.com/twall/jna/#getting_started" rel="nofollow noreferrer">JNA</a> would be of use. (if the performance hit for function calls through JNA isn't too bad)

blocks|key|347916|text|阅读乔尔在"Paying+down+your+technical+debt“上的帖子，然后现在就转换它，而不是在接下来的几年里支付利息，然后还清。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|347917|也许重新打包的库在更多的地方也是有用的。如果它们足够有用和复杂，足以让你考虑将它们保留在C中，那么一旦它们被很好地打包成可重用、易于分发和易于理解的类，它们肯定会有更多的用途。|347918|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codinghorror.com/blog/archives/001230.html^0|6|V|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Read Joel's receint post on "<a href="http://www.codinghorror.com/blog/archives/001230.html" rel="nofollow noreferrer">Paying down your technical debt</a>" then go ahead and convert it now rather than pay interest over the next couple years and then paying it off.

Perhaps the repackaged libraries could be useful in more places as well. If they are useful and complex enough to make you consider keeping them in C, they must have even more use once packaged nicely in reusable, easily distributable and understandable classes.

blocks|key|346482|text|简单的答案是，如果代码要被调用很多，而且性能很重要，那么就把它转换成Java。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346483|更复杂的答案是：|346484|346485|如果库很容易包装在JNI中，那么就使用JNI|unordered-list-item|346486|如果您的测试针对的是C/C%2B%2B代码很容易转换成Java，那么就使用|346487|346488|我会做以下事情：|346489|346490|采用其中一个算法，并将其封装在JNI|346491|中，采用相同的算法并将其转换为Java|346492|，看看做|346493|哪个更痛苦如果速度很重要，然后分析两个版本，看看哪一个是可接受的。|346494|<代码>F215|346495|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|13|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|G|7|18|8|@]|9|@]|A|$]]|$1|R|3|S|5|G|7|19|8|@]|9|@]|A|$]]|$1|T|3|U|5|G|7|1A|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1B|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|Y|$]]

The simple answer is, if the code is going to be called a lot AND performance matters then convert it over to Java.

The more complex answers are:

<ul>
<li>if the library easily wrapped in JNI then go with JNI</li>
<li>if the tests you have for the C/C++ code easily converted over to Java then go for the port</li>
</ul>

I would do the following:

<ul>
<li>take one of the algorithms and wrap it in JNI</li>
<li>take the same algorithm and convert it to Java</li>
<li>see which is more of a pain to do</li>
<li>if speed matters then profile both versions and see which of them is acceptable.</li>
</ul>

blocks|key|348744|text|C和Java之间的桥梁是昂贵的，所以如果你必须来回传递大量数据，那么调用C而不是JNI是不会成功的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|348745|我已经看到JNA被列为JNI的合理替代方案，以类似反射的方式从Java调用DLL/共享库中的方法要少得多。我还没试过呢。|348746|您可能需要考虑将C代码编译为可以用Java解释的Linux+MIPS二进制文件。速度相当快，但很难正确设置。请参阅http://nestedvm.ibex.org/|offset|length|348747|此外，您还可以使用到gcc的llvm后端来编译为低级字节码，然后可以在Java中解释这些字节码。THis也是Mac上的iPhone+SDK+afaik所采用的方法。|348748|entityMap|0|LINK|mutability|MUTABLE|url|http://nestedvm.ibex.org/^0|0|0|1L|P|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$F|U|G|V|1|W]]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

The bridge between C and Java is expensive, so if you have to pass a lot of data back and forth there is no win in calling C over JNI.

I have seen JNA listed as a reasonable alternative to JNI with a lot less pain to call methods in a DLL/shared library from Java in a reflection like way. I have not tried it yet.

You may want to consider compiling your C code as a Linux MIPS binary which can be interpreted in Java. Reasonably fast, a bit hard to set up correctly. See <a href="http://nestedvm.ibex.org/" rel="nofollow noreferrer">http://nestedvm.ibex.org/</a>

Also you may use a llvm backend to gcc to compile to lowlevel bytecodes which can then be interpreted in Java. THis is also the approach taken with the iPhone SDK afaik on Mac OS X. <a href="http://llvm.org/" rel="nofollow noreferrer">http://llvm.org/</a>

blocks|key|347982|text|我想您会发现，在开始使用JNI之前，使用JNI并不像看起来那么令人生畏。有一些重要的权衡和限制，但总的来说，JNI工作得很好，并且很容易按照您的意图加以利用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|347983|正如其他人所说，JNI最好的情况是：|347984|Java复杂的本机代码(如果该代码已经证明在reliable)|347985|Minimal和本机代码之间来回移动非常方便，这是额外的好处)(您希望最大限度地减少通过Java简单调用接口访问本机代码的次数(或者，如果您的本机代码需要利用|unordered-list-item|347986|
|347987|+objects/methods)|347988|
，也可以返回到Java语言|347989|为一组结构合理的本机组件自动或伪自动创建JNI层绝对是可能的。如果要包装的组件数量很大，这将是非常值得的。|347990|关于JNI的好消息是，构建和测试这个接口对您来说应该很简单，例如，您应该能够从Java编写利用现有算法行为的测试用例，如果有问题，问题很可能出在JNI层本身，而不是算法(假设您对本机实现有信心)。|347991|在我看来，用Java重写大量的C/C%2B%2B算法比使用JNI风险要大得多。当然，在不了解细节的情况下很难衡量，但我可以想象到影响算法实际实现的技术之间存在微妙的差异，更不用说纯粹的工程工作和错误风险了。|347992|最后要考虑的是这些算法或相关组件的未来寿命。这套算法是完整的还是不完整的，或者你还在继续添加？无论哪种方式，是否有强有力的维护和/或未来开发的理由来支持一种技术而不是另一种技术？例如，如果其他所有东西都是用Java编写的，所有新算法都是用Java编写的，而团队中几乎每个人都是用Java编写代码，那么从长远来看，用Java重新实现看起来更有吸引力。|347993|然而，即使这样说，工作胜过一致。对于大量功能良好的本机组件，我仍然倾向于从JNI开始，即使您打算长期过渡到Java。|347994|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|14|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|15|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|19|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1A|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|Z|$]]

I think you'll find that using JNI is not as daunting as it seems prior to diving in. There are some important trade-offs and limitations but in general JNI works well and is reasonably easy to leverage as you intend.

As other have said the best case for JNI is:

<ul>
<li>Complex native code (bonus points if that code has already proven very reliable)</li>
<li>Minimal back-and-forth between Java and native code (you want to minimize the trips across the JNI layer)</li>
<li>Reasonably simple calling interface to the native code (or also back to Java if you're native code needs to leverage Java objects/methods)</li>
</ul>

It is definitely possible to automate or pseudo-automate the creation of a JNI layer for a reasonably structured set of native components. That would be well worth it if the number of components to wrap is large.

The good news with JNI is that it should be straightforward for you to build and test this interface, for example you should be able to write test cases from Java that exploit existing algorithm behavior and if there are problems they would most likely be in the JNI layer itself and not the algorithms (given your confidence in the native implementation). 

Rewriting a large number of C/C++ algorithms in Java seems much more risky to me than using JNI. Without knowing the details it is hard to gauge, of course, but there are subtle differences between the technologies that I could imagine impacting the actual implementation of an algorithm, not to mention just the sheer engineering effort and risk of error.

A final consideration is future life of these algorithms or related components. Is the set of algorithms more or less complete, or are you continuing to add? Either way, is there a strong maintenance and/or future development reason to favor one technology over the other? For example, if everything else is in Java and all new algorithms will be in Java and almost everyone on the team is almost always coding in Java, reimplementing in Java starts to look more attractive long-term. 

However even with that said, working trumps consistent. For a large number of well-functioning native components I would still be inclined to start with JNI even if you were going to transition to Java long-term.

blocks|key|3125756|text|我也遇到过这种情况。我建议您习惯于使用Java中提供的多线程数据结构。此时，您将不再希望返回到C%2B%2B数据结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3125757|您还会意识到，使用更周到的技术、更好的多态性、适配器模式等，您可以更好地重写这些算法。|3125758|当你坐在C/C%2B%2B代码中时，你在想你想要抓住它。你在想你投入的所有爱。几年后，您将意识到，通过持有它并使用JNI，您已经创建了一个怪物。每次您遇到进程崩溃时，您都会后悔使用JNI。修复进程崩溃后，有人想要修改C%2B%2B中的算法，而您想要限制他们。他们会有一个方便的借口，比如“我还不习惯Java”。|3125759|看一看Java中的不可变数据结构。甚至不要考虑这些旧的C/C%2B%2B算法的执行速度。我发现我的新代码远远超过了我的任何旧C/C%2B%2B代码。|3125760|编写单元测试。使用NetBeans。|3125761|致以亲切的问候，|3125762|-Stosh|3125763|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I've been in this situation. I suggest that you get used to using the multi-threaded data structures that are available in Java. At this point you won't want to go back to your C++ data structures any more. 

You'll also realize that you can re-write those algorithms much better using more thoughtful techniques, better polymorphism, adapter patterns and so forth.

When you're sitting in the C/C++ code, you're thinking that you want to hang on to it. You're thinking about all the love you put into it. In a few years, you'll realize that by holding onto it and using JNI that you've created a monster. Every time you get a process crash you'll regret using JNI. After fixing the process crash, someone will want to modify an algorithm in C++ and you'll want to throttle them. They'll have a convenient excuse like "I'm not used to Java yet."

Take a look at immutable data structures in Java. Don't even think about the speed that these old C/C++ algorithms execute. I've found that my new code far out-paces any of my old C/C++ code.

Write unit tests. Use NetBeans.

Kind Regards,

-Stosh

I'm currently developing on a project written in Java. We have a bunch of algorithms written in C/C++ (at least a couple hundred) that need to be incorporated in our project. Our two options are to use JNI to call this code, or to rewrite all the algorithms in Java.

I am aware of the consequences of using JNI, it can open up a whole new set of problems, which is why rewriting all the code in Java is even being considered. But the thought of rewriting it seems...wrong. The algorithms have been tested and work as far as I know, they're just in the wrong language.

In this situation, would JNI make this task easy? Or would it cause more headache than rewriting the code in Java would?

<hr>

EDIT #1: Related Question - <a href="https://stackoverflow.com/questions/402408/usefulness-of-jni">Usefulness of JNI</a>

<hr>

EDIT #2: FYI - Our Java project is not meant to be portable in any way. That might eliminate one of the downsides of JNI in that it supposedly reduces portability.

Rewrite C code in Java or use JNI?

数据结构

单元测试

虚拟机

Windows

Linux

Java

我目前正在开发一个用Java编写的项目。我们有一堆用C/C++编写的算法(至少有几百种)需要合并到我们的项目中。我们的两个选择是使用JNI调用此代码，或者重写Java中的所有算法。我知道使用JNI的后果，它可能会带来一系列全新的问题，这就是为什么用Java重写所有代码都被考虑的原因。但是重写它的想法是seems...w...

问用Java重写C代码还是使用JNI？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用Java重写C代码还是使用JNI？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用Java重写C代码还是使用JNI？
EN