Oddly we’re coming full circle attempting to manage our own memory in Java to get performance out of GPUs again now :
Cas
bahahah xD
I’ll have to look into gamedev.net, thanks CaptianJester. As for sending people away. It’s not likely I’ll be defecting to C++ or GameDev.net x)
Huh, I’ll look into wxWidgets. Thanks.
This is the core issue, IMO. I’ve done commercial game development in C++ and the big difference is that you can just buy thirdparty systems for everything which work with C++. Not so with Java. It would be perfectly possible to do so with Java but C++ got there first and everything is designed to work with it. Existing studios see little value in completely retooling to use an unproved (to them) language.
Not having a good story targeting PS3/Xbox doesn’t help either.
None of this is inheirently a Java issue, it’s more to do with game developer studios expectations and beliefs.
WxWindows is the spawn of the devil. I’ve used a great number of GUI systems in my life and WxWindows is hands down the worst. Any system that makes heavy use of #define macros to do real programming needs a special level of hell all of it’s own.
Although it’s certainly true that C++ only programmers assume Java is worse that it actually is and conversely that Java only programmers are certain that it’s better than actually is. There are very real (and huge) downsides to using Java for a large budget game projects esp. if they are attempt to be cutting edge.
The ironic thing is that the main reason I use Java, other than its robustness (no pointer BS to deal with, no typos showing up only as segfaults), is for the vast number of third party libraries available for it. But code libraries and apps in the asset pipeline aren’t exactly the same thing are they.
It’s also safe to say that for games that really need to squeeze the utmost out of the platform, that the Java runtime imposes some pretty severe limitations that you can only get around by “writing C in Java”. JNI is a non-starter, it has overhead of the likes of COM, so it’s a price that devs are only willing to pay once (namely for DirectX). You can statically compile, but then it’s back to the high marginal cost of switching your toolchain just to switch source languages.
Hm agreed, but in my experience most cross-platform C++ APIs work like that in one way or another with the exception of a small number of very clean ones (often ones that are quite young - WxWidgets is already quite old). But now I’m curious: you know a better alternative for C++?
If JNI wasn’t so obscure and difficult to use properly, I should think that the C++ library integration problem would largely “go away”. IMO the whole design of JNI - whilst admirably ensuring that C++ code talks to “an arbitrary implementation of a JVM” correctly - was/is utter bollocks, there being for most of Java’s history only one JVM implementation that mattered, and native code being native code anyway, why did it have to be compatible with arbitrary JVMs in the first place?
No, I think they should have shortcut the entire thing and just made it trivial to call into and out of native code from C++ and we’d be years ahead.
Cas
Yeah they should have gone with a simple native stack ABI and called it done. FYI eons ago I did a interpreted only JVM that was fully compliant at the VM level (minus identityHashCode and per object synchronization, both of which are stupid). Without JNI the memory footprint was around 3-5K for both intel & ARM, including a stack based ABI. With JNI it shot up to around 25K if memory serves…and JNI interface was insanely slower.
Your first point I agree with, though I do see the benefits of having a defined standard across all JVM, particularly heading forward. With regards to JNI, I’m definitely converted to the benefits of JNA, BridJ, etc. Far easier development and deployment, with negligible* extra overhead.
I am intrigued by what “calls between Java and Native without JNI boilerplate” means for JDK 9. I’m assuming (possibly wrongly) that this means the equivalent of JNA / BridJ within the JVM.
Best wishes, Neil
- IMO negligible because 99% of the time if you’re doing so much back and forth between Java and native code that this becomes an issue, you’re not doing it right!
PS. I’ll be ignoring Julien’s obligatory anti-JNA rant! 
JNA has even more call overhead than JNI, it’s just not as baroque at the source level. I’d not heard of BridJ before, but it sure looks interesting.
Er, I know, that’s what I said! However, in practice I find the call overhead swamped by other factors anyway (like actual calculations!) which is as it should be unless you’re doing something unusual (or stupid ). JNA is improving too - I recently helped get a callback fix into it which sped up calls into the JVM quite substantially.
One of the JAudioLibs libraries in my sig is a binding to the JACK audio library using JNA. Low-latency audio running at realtime priority, and JNA copes admirably.
Actually, no. Usually, you only say that we are wrong. Admit that JNA is slower than JNI once for all.
I’m reasonably sure that nsigma wasn’t addressing performance in his statement.
I suggest we leave it at that, as nobody wants a flamewar in this otherwise informative thread. :point:
I beg to differ, it’s on.
Did someone say Julien’s name three times in a mirror? Fess up!
Memory usage is definitely worse than C/C++. Execution speed is a little slower (although, for AAA much of the heavy lifting is done by the Gfx Card - language doesn’t matter there). If you have to be able to use CPU specific features that forces JNI which isn’t the fastest thing around.
For most games I think only memory footprint is likely to be a deal-breaker.
The last time I had to do a GUI in C++, I wrote an OpenGL library that basically mimicked Swing :o)
I was under the impression that the GCC Java compiler had some way of interfacing directly with C/C++ code. I believe that the compiled Java binary object was pretty much the the same as the output for C or C++. Did GCJ ever amount to anything?
GCJ is a static compiler for Java, so its interface is like any other native code. And it’s safe to say that no, it never amounted to anything. The code it generates is slow, and the memory footprint is large, and the gc is basically broken. It has faster startup, that’s about it.