I recently released a new version of a game I was writing and someone replied that it won’t run with his Java 8.
I tried installing the latest JDK on my Win 7 PC. It said it loaded fine. I then tried to see whether it was running fine with
java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
So am I running Java 8?
Will users with Java 7 now not be able to play?
Is there a simple solution?
Actually I just want people to be able to play the game with as few problems as possible. I don’t care too much how I do it. This is what I’ve tried so far:
I initially started with applets but they became unfashionable and people said web start was the way forward.
I genuinely thought web start was the bees knees as it installed on user PC’s, I could still release updates and I could set java versions etc, etc. Then they changed the licensing/security thing and it effectively meant I couldn’t use it.
I then tried as a java application but users genuinely just wanted an exe.
I could only create the exe’s with help and obviously it will only run on PC’s doing this.
I’m now trying the jar application approach again but I’m getting issues with users having different versions of java.
I really just want people to be able to click the game and be able to run it without issues.
It does seem strange that something would run in Java 7 but not Java 8. If I were you, I’d want to track down what’s causing that. Have you tried completely uninstalling all Java from your system, then installing Java 8? Can you have your friend run your jar via the command prompt to see any errors that are happening? Maybe it works on your machine but not on others because of some resource?
You might want to check out JWrapper, which can export your Java application as a platform specific application for any of the major operating systems.
But this discussion always spawns a debate about the best tool to use. Here comes gouessej in 3, 2, 1… ;D
For the record: I don’t have any problem with gouessej’s tool, in fact I’ve never tried it.
My preferred method of deployment is to use libGDX, export to html5 for a demo that everybody can try (no install, no Java, no whatever), then have a “full” Android app. That’s actually what I’m working on right now, getting libGDX deployment to work on my site.
For Java applications, I prefer to just use a jar. I understand that “real” games should use an installer, but that’s overkill for most of my little projects (and, if we’re being honest, for most of the projects on this forum). If I was the OP, I’d be focusing on why the game isn’t working on Java 8, not trying to find a workaround.
So I don’t really have a horse in this race. My only argument is that there’s more than one way to skin a cat. Somebody might even use JWrapper to export to Windows and Mac, then use gouessej’s tool for GNU.
I just think it’s funny that we have this discussion every time somebody asks about packing the JRE with a game!
Mike, I highly suggest you figure out why the game doesn’t work. It might be that you forgot to include a resource that’s only on your computer, or it requires some native library, etc. This has nothing to do with the version of Java you’re using, so any work you put in towards any of the suggestions any of us have given you will be wasted time.
Have your friend run your jar through the command prompt. Does he see any errors there?
Or if you want to test Java 8 on your system- mostly all you need to do is modify your PATH variable to point to Java 8. Or if you want to be absolutely sure, first uninstall every version of Java from your computer completely, then install Java 8.
If you compile your program with Java 8, then by default, people with Java 7 (or 6 or 5 or 4 or…) will not be able to run your jar. There are compiler settings (I think ags1 mentioned them above) to get around that.
However, the reverse is not true: code compiled in Java 7 should work for somebody running it with Java 8 (or 9 or 10 or…). That’s why it’s weird that your friend can’t run your program, and it’s why I suspect the problem is not what you think it is.
I would bet that your friend is either running Java 6 (which can’t run code compiled with Java 7, unless you use the compiler settings ags1 pointed out), or there’s a missing resource.
You might also link us to the jar so we can try it ourselves.
I’m quite willing to give it a try.
Is your tool easy to use (for a novice)?
My OS is Win7.
I have a standard jar. There’s no file access etc. My jar runs fine on Java7 (I assume it would run on 8 but I’m guessing here).
The app gets called with “java -jar -Dsun.java2d.noddraw=true AlienSwarm.jar” which fixes a problem with some drivers not working at 640x480 res.
I d have Ubuntu running on a laptop but the game won’t run in full screen mode on my laptop for some annoying reason plus the sound never seems to work properly in Linux.
You just need to understand a very little bit XML as it uses Ant. However, it’s under GPL which is a viral license. If it’s a problem for you, rather use PackR.
PackR and JNDT allow you to pass arguments to the VM. As you already have a fat JAR, it should be very easy to make it work.
There is an unfixed bug in AWT under GNU Linux that breaks the full screen mode, the task bar is always drawn above the window This bug is fixed in some libraries including NEWT (native windowing toolkit of JOGL, part of JogAmp). It’s possible to use NEWT with AWT, Swing, SWT and (indirectly) OpenJFX/JavaFX.
I assume that you use JavaSound. If you want to have a better sound support, ask nsigma to help you with JavaSound or switch to OpenAL. I use Paul Lamb Sound Library with its JOAL plugin, it’s a good compromise as it solves the main problem with OpenAL without learning how to use it as it’s quite high level. Moreover, JOAL uses OpenAL-Soft in priority which means that you don’t need OpenAL installed on the system, it’s as convenient as using JavaSound.
I must admit I think we have different definitions of the phrase “easy to use”
I was hoping to download a tool, click on my jar and magically get an exe I could give out.
I read your post a few times and I’ll admit I’m not sure how to proceed.
Mike
If you don’t understand how a tool works because it is magic, how do you fix it if it stops working or if its terms of use become unacceptable for you?
Press CTRL+F, look for “create-windows-app-bundle” in this Ant build file, copy/paste 3 files of XML code and modify it to fit into your needs… Use PackR instead, it’s explained here, download a single JAR and run it in command line as indicated in the example. If you consider a tool too much complicated just because it has no GUI, I can do nothing for you. I advise you to use PackR because its documentation is better than mine and because I assume that your games aren’t under GPL. Please don’t tell me that using a single command line is terribly difficult.
Edit.: If you just want a single Windows executable, use Launch4J:
You’re right princec but nothing forces her/him/them to fix it (it’s true for free softwares too). When you have access to the source code, you have a chance to fix it by yourself without doing some reverse engineering. JarSplice is a good example, it’s widely used, it contains some unfixed bugs, its source code isn’t available and some developers have complained about that for years: http://ninjacave.com/jarsplice
mike_bike_kite, I’m not completely blinkered, I will improve the documentation of my tool soon and I will put JNDT into JFPSM. In other words, it will be possible to use my tool in a (not magic, free software) GUI. It will require a lot of work, I will probably have to rewrite it in Java. However, I still advise you to choose a tool whose terms of use are compatible with your projects. You seem to use Launch4j according to your website, what is wrong with it? It seems to create only a native launcher but not a single executable. I don’t advise you to use JSmooth as its maintenance was stopped in 2007 as far as I know and it doesn’t support 64-bit micro-processors.
Edit.: I’d like to support MSI in order to provide a single Microsoft installer instead of an archive so that the end user doesn’t have to understand how Java works and it seems to be less difficult to implement than putting everything into a single executable file.
This bug is fixed in some libraries including NEWT (native windowing toolkit of JOGL, part of JogAmp). It’s possible to use NEWT with AWT, Swing, SWT and (indirectly) OpenJFX/JavaFX.