3 ms·
All good stuff. But I have heard JNI is already multiple times faster than Go's cgo stuff so I wonder what could be improved there.
by geodel 10y ago
All good stuff. But I have heard JNI is already multiple times faster than Go's cgo stuff so I wonder what could be improved there.
- pjmlp 10y agoAccording to Mark Reinhold, Sun designed JNI to be hard on purpose, to discourage developers to write native code. He has repeated this a few times at his JavaONE presentations, a bit hard to track down which ones. Thanks to the work of Charles Nutter on adding FFI to JRuby, and the pressure from FinTech to improve Java's mechanical sympathy, a new project was started, project Panama, where binding to native code from Java should be something like P/Invoke on the CLR. Similarly calling into Java APIs from native side should have less ceremony setting up what to call. Additionally there should be a standard support for integrating GPGPU into Java. As it was deemed too complex to be ready by Java 9 timeframe, it ended up being scheduled for 10+ roadmap. For the latest status check "Going Native" at JVM Language Summit 2016. https://www.youtube.com/watch?v=JR1zI5gLhRM&index=13&list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_ https://www.youtube.com/watch?v=JR1zI5gLhRM&index=13&list=PL...
- geodel 10y agoInteresting talk. Go folks also probably want cgo similarly difficult to use. Though for them I guess it will work, as they have already written compiler/GC/runtime/ssl etc in Go plus some asm.
- pjmlp 10y agoI never understood why cgo was an option instead of doing what most languages do. The only reason I see, was having an easier way to parse header files.