Can't run Breakout outside of appliance

Question

I have just finished implementing Breakout, and tried running it outside of the appliance in my Debian machine, but i get the following error, even though it's the same directory that's shared between the VM and the host :

Exception in thread "main" java.lang.UnsupportedClassVersionError: stanford/spl/JavaBackEnd : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:643) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:323) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) Could not find the main class: stanford.spl.JavaBackEnd. Program will exit.

$ java -version
java version "1.6.0_31"
OpenJDK Runtime Environment (IcedTea6 1.13.3) (6b31-1.13.3-1~deb7u1)
OpenJDK Server VM (build 23.25-b01, mixed mode)

Any thoughts on why this is happening?

Answer 1

As Kareem said in his comment, you need to recompile your code in the Debian environment in order to run it in that environment.

When you compile C source code, the compiler translates it into the appropriate machine code for the current system. This is why a lot of software comes in different versions for different operating systems. Each Linux distribution is a different operating system built on top of the Linux kernel.

Sometimes the source code can be written in a way that accounts for differences between operating systems. For example, this may be necessary for new programs to be compatible with older versions of the same OS.

Languages like Java are "cross-platform" so that the same source code can run on multiple operating systems without modification. In the case of Java, the way this works is that the code is compiled to Java bytecode, which is translated by the Java Virtual Machine into machine code when you run the program. This is why you need to install the Java environment before you can run programs written in Java; it takes away the requirement for the programmer to write and compile many different source packages, and adds a requirement for each user to install the particular Java environment that works with their system.

The reason you're seeing errors related to Java is because spl (the Stanford Portable Library) gives students the ability to write code in whichever language they are learning and have it translated to and implemented in Java. One of the advantages of using spl is that students can use generally the same interface to write their first graphical programs even if they are taking different classes and learning different languages. (A more detailed discussion of the project is available in a 2013 paper by Eric Roberts and Keith Schwarz of Stanford University.)

If you were implementing breakout purely in Java, you wouldn't need to recompile, but C is not a "cross-platform" language, so you will need to compile your code from the Debian environment in order to get machine code that Debian can understand.

As @AJPennster points out, you also need to make sure you have access to all of the appropriate dependencies in the new environment.

Answer 2

You need to recompile the c source in order to get a binary file that the Debian system can execute. However, even if you compile for your Debian system, you will run into some more problems. The SPL library that provides the graphic objects is not available in source. It is compiled for the Fedora 32 bit system. Which means that even though your source code will work on your Debian system, when it tries to execute functions from the library, the system will report missing functions, even though the library is already there. You will run into the same issue as before, when trying to run executables that were compiled under Fedora in a Debian distro.

In the pset4 directory, look at the file under spl->lib. You will see that it is a ".a" file. This is the library file, that contains all the instructions and functions that the library provides.