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.
I have NFI when it comes to things like this, but anyway…
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.
nerb.
PS. Just for your reference, it runs fine for me. I’m running Windows 7 and Java SE 7u25.
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.
Thanks guys, i’ll try the maze thing nerb, and CodeHead That makes a lot of sense, can i compile this for java 6 without reinstalling java? or do i need to install an older version of java?
Is it possible that it’s because i made it with a 64 bit machine and their running 32 bit?
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:
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. :emo:
@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. 8)
@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. :o
