Java and Steam JVM deployment

Question

I am currently considering my options for game development and deploying to Steam Greenlight. I really like Java with libGDX, especially for its cross platform Android potential, and I understand that it is possible to deploy Java games on Steam. I am also very comfortable with having to create some sort of wrapper so that my Java game could call into the C++ Steamworks API.

My question is about what deployment problems I might run into. Specifically, with the client machine's installation of the JRE. I have seen many Steam installers check for the .NET runtime. Should I do a similar check and install for the JRE?

Are there any glaring reasons why Java deployment on Steam would be a nightmare to deploy and maintain vs something like C# using Monogame?

Answer 1

As someone who has recently released a libGDX game on Steam, unlike .NET and DirectX, Steam does not provide an option with your application to automatically check and download the version you need of those libraries.

It's obtrusive to the user to make them install Java as a system library, as most still view the JRE, especially Oracle's, as some kind of adware/security hole and do not want to have it installed on their machine. There is still a stigma towards Java applications on the desktop, so you have to be considerate of the user.

What I recommend is using libgdx's packr application, which will automatically pack your jar and resources with an appropriate, private OpenJDK which is open to use and distribute with your software. Alternatively, you can do it manually by grabbing the unofficial OpenJDK build that they are using in packr and including it with your project.

I, personally, do that latter option as I have downloading the latest version and packing everything up, including distributing to steam, all included in my project's gradle build script.

Including your own JRE/JDK is lightweight, only adding about 80mb to your game, and is non-invasive. This also insures that the version of Java that you are running your application with is always the version that you need, instead of conflicting with what the system has.

Edit: March 13, 2017

For a little over a year now I've been using Azul's OpenJRE instead of the unofficial builds from alexkasko. They're widely used and supported even in enterprise environments. Additionally, they support Java 8 and up, where as at the time of my switch the unofficial build repository versions were stuck at Java 7.

Since I switched, there is now an open-source repository as well, that continues to provide community built versions of the openjdk/jre, if you wish to use that instead. Both are good.

Answer 2

I think that it is absolutely OK to check the user's runtime, given the language requires one. I think that in .NET, Java, Python, Lua, or other programming languages that require a runtime environment, simply because the game cannot run without it.

If you have UX concerns, don't worry, the JRE installer is not very intrusive, and many games get away with runtime installations, or even multiple dependencies.

In terms of legal concerns, I don't believe that you are in any grey or red zones of the law. According to the License FAQ, you can quite simply distribute the Java Environment with you're software, according to the item stating:

Can I distribute Java with my software?
Yes, you can provide Java with your software provided you abide by the terms and conditions of Java binary code license

That should be all the information you need to make an educated decision.

Answer 3

Some users may not have Java installed and I don't believe that Steam has a native way of checking for / installing Java as that would be irritating for the user and only a small minority of games on Steam require Java.

Try including a portable Java Runtime Environment so that you will always have a consistent build of Java to run the game on, I'm sure there are some around that will suit your needs.

Answer 4

Java development can be a nightmare as far as deployment; but, there are tools to make this easier.

For example, you can use a tool like Launch4j to package up your final game; optionally, you can tell it to include the JRE (or not) in order to create a fully self-contained binary.

This way, you don't care if or what JREs the client has installled; you just package up your app, and ship it. The downside is that your final binary will be significantly larger.