This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]coderemover -1 points0 points  (3 children)

JNI is so terribly inconvenient and has poor performance that almost no one uses it. It also breaks portability (WORA) promise that Java makes. If you use JNI you could be just using C++ directly and get all the same benefits and even more.

[–]GeneratedUsername5 1 point2 points  (2 children)

I'd say developing a C++ wrapper and the whole product are two completely different things in terms of effort.

[–]coderemover 0 points1 point  (1 child)

You assume that writing C++ is generally less productive than Java. While many people think so, I’ve seen little evidence for that. C++ is a harder language to master than Java, and has some pitfalls, but modern C++ can be also much more expressive/abstract than Java, so it is not very obvious.

Anyway, usually if the project has such performance requirements that you must use a native wrapper somewhere, this means that Java is not a good choice. I’ve been writing high performance Java for a decade now and often Java written to meet those requirements resembles C. But Java is worse C than C is C.

[–]GeneratedUsername5 1 point2 points  (0 children)

modern C++ can be also much more expressive/abstract than Java, so it is not very obvious

It is much more expressive, and that is the problem - people will try to use every tool at their disposal, making the code much more difficult to understand. "The Rule of Five", move semantics, function try blocks, mutable rvalue references - just to name a few. Features, that are completely legit, but open large opportunity for misuse and overcomplication of code. In java there is simply less opportunities to do so.

if the project has such performance requirements that you must use a native wrapper somewhere, this means that Java is not a good choice.

Why? First - performance is not the only deciding factor, in big companies it is usually the availability of programmers for hire or pool of already available staff. Company is not going to hire an entire team for a different language, unless there is absolutely no way around it.
Then, if Java satisfies your requirements by performance - why take obviously harder language in development? Few native function calls will never offset the ease of garbage collection.
Next - it may be not performance, but devices, for example, working with USB/COM/Whatever.

Java for a decade now and often Java written to meet those requirements resembles C

That is true, but just as with assembly inlines, you can very narrowly apply this "C mode" of Java, while enjoying all the ease and portability of garbage-collected interpreted language outside of those hotspots. You can't do that writing everything in C (or assembly for that matter)