We do this as well, targeting Mac, Windows, Linux, iOS and Android with the same C++ core libs. It seemed to be the only way to target multiple platforms without a huge team. It's not all easy though, the work of maintaining the JNI bridge is large, even with most of the code being generated automatically, With the woeful state of native debugging on Android it may have been almost as easy to recode in Java, but maintaining two code bases would have been a real hassle, its hard enough keeping all the UI's in sync.
Same here, C++ for the business logic, maths, engine, etc., OpenGL for the graphics, and then a relatively thin platform-specific layer of Obj-C,Java/JNI,Qt just for the UI. Saved a lot in terms of not having to have multiple teams basically writing the same stuff in different languages.
One of the weirdest things we had to overcome was actually the cultural aspect. For the Linux client, nobody had any problem with the architecture: Get the Qt client working and hook it up to the plumbing. Done. For the iOS guys, still no problem, but let's make sure we separate the C++ cleanly from the Objective-C through a solid, well-understood interface so our food doesn't mix. The Java guys basically threw a hissy fit, objecting to all of this C++ nonsense infecting the purity of their Java. Every time the app crashed: they blamed the C++ code. Every performance problem was because C++. Grandma got sick? C++. When tracking down a bug, they'd step through their Java layer, and as soon as it hit the JNI, they'd just stop and file a bug to the core team rather than dirty themselves stepping through C++. They culturally wouldn't accept C++, and wanted to instead have a separate parallel tree with Java business logic, Java math, Java graphics, etc. The hard reality, however, was that the Android client wasn't bringing in enough revenue to justify a full parallel team and code base. Despite all the grumbling, going the C++ route was a huge success, letting us support multiple platforms with mostly the same code base.
I'm curious as to whether this borderline religious anti-C++ attitude is common in the Java/Android ecosystem, or an outlier? I found it really bizarre.
> I'm curious as to whether this borderline religious anti-C++ attitude is common in the Java/Android ecosystem, or an outlier? I found it really bizarre.
It's a well known result of theory and practice among people who start delving into more provably safe languages.
It's a common article of faith among Java guys, who will tell you that there is no way you can write a safe program in a native language, although they can't really say why (it's effectively hearsay) other than pointers are involved. If Gosling said to use Java, who are they to question it?
For fun, mention that OpenJDK has over a million lines of native code (C and C++: https://gist.github.com/shipilev/2fddb1d2943a4cbb6080 ). Looking at the numbers for the hotspot directory, more than 2/3 of the code in the JVM itself is native code. I realize that this is caused by bootstrapping issues. But if someone believes it is truly impossible to write safe and secure native code, ask how they can trust the JVM to correctly run their safe program, given that it has so much native code.
I know the old argument was that it was easier to audit the (small) amount of native code in the JVM than the code in your specific project. But half a million lines isn't small by any definition I'm aware of. It's larger than any native projects I've worked on.
It's quite likely that the skill and experience level of the average OpenJDK Hotspot committer is a couple notches above the average... and to them things like the manual resource management you have to put up with in C/C++ are not a pointless distraction from their business problem, they are a core part of it.
Besides there are JVMs implemented in Java too, just not with as high performance as Hotspot... search for Maxine or Jikes RVM.
So is it possible to write safe software in a native/unsafe/unmanaged language if you know what you're doing? Wow, that's exactly what I tell people, but it isn't what you read on the first page of any number of Java programming books (of course, those books tell you that you must do manual resource management in C or C++ which is not, in fact, true ( e.g., http://www.apachetutor.org/dev/pools and http://www.artima.com/intv/modern3.html )).
And, really, who wants to use a language designed for people who don't know what they're doing?
I'm not saying that it's impossible to write a JVM in a managed language. Just that it's funny to hear people talk about native languages with a hint of fear, and then run their "safe" programs on a VM that is implemented with a half million lines of C and C++.
SDL was ok for games, but now with a real app, I tried the Qt way, only to discover there are still lots of issues.
So I figured out, better use JNI and C++/CX directly and save the pain of figuring out bugs in Qt.
In the end, the JNI pain is bigger than figuring out Qt bugs and helping those guys.
For small devshops there is a lot of time to be saved by letting third parties like Digia and Xamarin have to go through the pain of writing platform specific wrappers.
If I was doing mobile OSs for work, I would gladly pay for them.
