What Java do wrong -- JNI

The question come to my mind that why it is just painful to reuse exiting code in Java,  where "existing code" was written in other programming language. I use Eclipse everyday and use it with git.

The performance of Eclipse (JGIT/EGIT) is absolutely unacceptable as slow as a snail when you compare it with the good git command line tool. Try a git blame or log on a sized and historical project and everyone can tell the different.

I read http://githubengineering.com/move-fast/ today and it is interesting that they did code in bash and ruby, which supposed to be slower than Java, actually run faster and dev faster then jgit. I believe that it is because they can reuse existing code and library.

If you compare the Java community with some other popular non-native programming languages(e.g. ruby, python, node.js). You find that nobody re-implement git in each language, but write a binder and wrap native lib(libgit2) or sub-process(git cli) and focus on their own job. Some interesting project even try to transpile from source or from binary (e.g. C into asm.js).

But things different in Java. They hate native codes and hate JNI. While the rest of the world rewrite performance critical path into C, Java rewrite them into Java (to reduce context switch).

It is real that even in a project (Oh, did I mean Eclipse?) targeted to selected platforms (not everywhere), they fork and re-implement missing features in Java and forget what they should focus on.

The design of JNI is just wrong.

• It is too easy to make mistake

• You have to write Java in C to use C library in Java. (javah and jni.h)

• You will need extra configuration (java.library.path)

• You need extra code (System.loadLibrary / System.load)

• Programmers still trying to make their code run everywhere.

JNA is trying to fix that, by avoid writing the middle JNI codes, still not a standard. There is a proposed standard JEP 191, but it is no progress until Java10.