Here's an old post I made on the subject,
As I said, I might have been a bit out of date on Eternity :-p
As for C++, sure, porting "clean" (HA!) code should not be a burden, but wait a minute, what flavor of C++ are we talking about? Borland? Microsoft? GNU? And with what OS-specific assumptions, headers and libraries? If the situation with plain C is just "ugly" when it comes to cross-platform support, with C++ it escalates to downright "fugly". How many #ifdefs will be needed to save the day?
Well, it *is* impure. In the case of Doom ports on Android, all the real "doom" work is done on the native library's side (almost like a doom-on-a-stick), and Java is just there to avoid writing the UI in NDK :-p
Maes just considers the JNI thing "impure", compared to a "pure" Java-only port.
Writing stuff with JNI wrappers is also a hideously non-portable option, much more than even a native executable, effectively tying you to not only a specific CPU, but also a specific OS and JVM, depending on how "clean" (an oxymoron, in this case) a JNI app you write. You can make certain very nasty things happen if you try sharing structured data between the two "worlds" during runtime, and rely on memory layout assumptions. These might change even between different JVMs, thus making any JNI app a one-time hack. "But it worked on my computer" squared and cubed.
Why would I be upset about those? I am counting on them to do just that ;-) I have a colleague who tried to write his own class loader with real-time bytecode manipulation for some extremely convoluted task, though. It was not pretty. However, a pure Java port of Wolfenstein 3D with real-time, generated-bytecode, optimized column drawer functions would be a tantalizing idea ;-)
I say we bombard him with some stuff about how the Dalvik and Hotspot VMs JIT compile Java bytecode into platform-specific instructions, and that it would be way more "pure" to write your application in those instructions in the first place ;).
Last edited by Maes on Aug 24 2012 at 20:03