So i created an entry for the latest LD but i found out half of the people who try it can't even play it, i tested it on another machine and i got an error about it not being able to find the "main class: maze.maze."

Here's a public link to my latest attempt at getting it to work. I always tend to have a lot of trouble with exporting these jar's.

Your package is named 'Maze'. Rename this to lower-case 'maze'. As directly quoted from the Java Tutorials: "Package names are written in all lower case to avoid conflict with the names of classes or interfaces". I'm guessing there may be a conflict between your package Maze, and your class Maze.

If that fails, start thinking about what is common between users for whom the program fails to run. I.e. OS, Java version etc.

Just tested it on my machine and had no problems (Java 7 - Arch Linux). If you could post the specific error code here, that would be helpful. Since it seems to work fine on some machines, but not others, I have a nagging feeling that it's going to come down to the minimum Java version not being met on the machines with the issues. Check to see the version of Java the "problem machines" are running if possible. Also, if you compiled this for Java 7, then be aware that there are still a lot of machines running version 6 of Java out there which can aggravate deployment problems if you don't plan for it.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

I can't say I'm convinced it's a Java 7 issue. Sinuath's source doesn't appear to use any new Java 7 features that would be incompatible with older versions. Not to mention if it did, I'd expect the error to be different, and occurring elsewhere??? Surely older versions are still able to find the main class of a Java 7 program?

Nonetheless, let us know how you go Sinuath. Will be interesting and handy to know what the problem is.

@Cylab: Will that actually do any good in this situation? Looking at the javac version 7 options, I found the following:

Quote

-target versionGenerate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), and 1.7 (also 7).The default for -target depends on the value of -source:

If -source is not specified, the value of -target is 1.7If -source is 1.2, the value of -target is 1.4If -source is 1.3, the value of -target is 1.4If -source is 1.5, the value of -target is 1.7If -source is 1.6, the value of -target is 1.7For all other values of -source, the value of -target is the value of -source.

From that it would sound like you could limit your source files to use only features available in Java 6, but the minimum target platform is still going to be Java 7.

@nerb: Java is backwards compatible, not forward. Trying to run a newer .jar file in an older JVM usually causes Java to throw an exception on start-up. I can't recall the exact wording off the top of my head, but I've seen it happen plenty of times where I work when we deploy newer tools.

@Sinuath: You can actually have multiple JDK's on the same machine at the same time. It's a bit of a pain to get set up at first, but I can say from experience it does work. The third answer down (and a few below that) on this SO page explains what needs to be done.

A much easier option would be to require Java 7 to play the game. If you're worried about end users not wanting to install/update their JRE, you can package a standalone version of Java with your application. There are more than a few threads around here explaining the process.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

@Cylab: Will that actually do any good in this situation? Looking at the javac version 7 options, I found the following:

Quote

-target versionGenerate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), and 1.7 (also 7).The default for -target depends on the value of -source:

If -source is not specified, the value of -target is 1.7If -source is 1.2, the value of -target is 1.4If -source is 1.3, the value of -target is 1.4If -source is 1.5, the value of -target is 1.7If -source is 1.6, the value of -target is 1.7For all other values of -source, the value of -target is the value of -source.

From that it would sound like you could limit your source files to use only features available in Java 6, but the minimum target platform is still going to be Java 7.

The versions listed are only the default values, if no explicit -target is specified. Specifying -source 1.6 and -target 1.6 works fine.

@Cylab: Have you been able to successfully do this? I ask out of genuine curiosity since it would streamline my development pipeline at work.

The compatibility docs for Java 7 seem to indicate there is a binary level incompatibility between JRE6 and the class files produced by JDK7 (im assuming even with the source and target flags used for compilation). I would test it myself, but I don't have access to JDK7 on my work machine, and trying to get our ISD department to install software is a multi-day, multi-manager approval process.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

The compatibility docs for Java 7 seem to indicate there is a binary level incompatibility between JRE6 and the class files produced by JDK7 (im assuming even with the source and target flags used for compilation).

The article only contains that

Quote

Version 51 class files produced by the Java SE 7 compiler cannot be used in Java SE 6.

-target versionGenerate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), and 1.7 (also 7).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org