Java Wrapper Around C++ Application

Yes. You'd have to compile most of the code in to a dynamic library in order to load it via JNI and call the "native" entry point. However, you'd have to create one such dynamic library for all platforms and architectures you want the code to run on and have JNLP send the correct one.

IMHO, there's very little point in doing this if your code only runs on one OS and platform.

Thanks. I was planning on compiling the C++ code for all major platforms. I think that deploying as an applet (or JNLP, haven't looked into this much) makes people more likely to try out your game or play it when they aren't on their usual computer.

I can only speak for myself, of course, but... for one thing, usage of Java in any form makes me basically disregard your software entirely. With very few exceptions I don't see much Java software that's worth running. For another thing, if I'm interested in testing it out, I'll do so on my regular machines - not just some random box. And in that case, having a source or binary package to build for my selected platform is worth far more than some kind of half-workaround involving Java.

Thanks. I was planning on compiling the C++ code for all major platforms. I think that deploying as an applet (or JNLP, haven't looked into this much) makes people more likely to try out your game or play it when they aren't on their usual computer.

This is a solution, looking for a problem. Sure, it can be done. But given a list of viable options to achieve any kind of goal, such hosting would be towards very end.

1. Java and Applets do not reduce user friction. Ignoring the usual issues with OSX no longer including Java, JVM in browser still suffering from race condition which causes applications to fail to start randomly, The Oracle/Java/Duke logo is, for many, user repellant.

2. Native code requires all kinds of permissions to run. In case of Java it results in a very ugly dialog popping up, warning about credit card theft, rape, murder and kicking kittens. Some will be bothered and chose to close, others will ignore it. But it does no favors to application, at best it completely ruins the visual style.

3. Third party libraries. Native code is ok, but often requires third-party libraries, some of which are not available in source form or may not be linked statically. In practice, native applications must be installed natively.

4. Portability. "major platforms" is very vague. Considering there are 2 types of Java (32 and 64 bit), 2 types of OSes (32 and 64 bit) and several OS versions (XP, Vista, 7), the number of systems that would need to be tested and supported is huge. 20-50. This isn't even counting the browser issues.

5. OGL. DX is out of the question, so it's OpenGL. Except that debugging OGL for this type of "casual" user is a nightmare. Most will be running 5 year old buggy and incomplete drivers on inferior graphics cards. Doing all of this in pure Java is hard and tedious enough.


If you need portability, use pure Java.
If you want ease of use, use Flash.
If you need to support iOS, use iOS.
Or, if you're absolutely desperate, use adobe air.


Using Java+C++ to solve friction issues is wrong tool for wrong problem. The real problem is marketing. No software can solve that.