• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

class file portability

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had thought that the .class file one created after compiling a piece of java code was supposed to run under a different operating system. I tested this with some simple java code

public class HelloWorldApp {
public HelloWorldApp() {
}
public static void main(String[] args) {
System.out.println("Hello World!");
}
}

I compiled it to a .class file on my home machine (Win XP). It runs fine. I transfered the .class file to my office machine (Linux). It won't run. If I Compile it on my office machine, the resulting .class file runs fine.
However, I thought the .class file itself was supposed to be portable, not just the original uncompiled code. It is true that at home I have Java 1.6.0 and at work I have Java 1.5.0_02-b09, but does that small of a difference really mess up "write once, run anywhere"?

-John

Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes it does matter, Sun's version naming is a little screwy. From what I understand they are trying to change that so the versions are more 'normal'. Java 1.5 = Java 5, Java 1.6 = Java 6. Code compiled under Java 5 should run under Java 6 but not the other way around.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Class files from a newer version of Java in most cases do not run on an older version of Java. So if you compiled your code with JDK 6, and try to run it on Java 5 then you'll get an error like this. The other way around it obviously works without problems; you can run a class compiled with JDK 5 on Java 6.

Note that the Java compiler has command line switches you can use, -source and -target, that you can use to specify that you want class files compatible with a particular Java version. That way you can compile Java class files with JDK 6 that run on an older version. But note, if you are using classes or methods in your code that are new in version 6 of the standard Java API, it will ofcourse still not work on the older Java version.

Note that the operating system doesn't matter, only the Java version. Code compiled with JDK 6 will run on any JRE version 6 or higher on any operating system.
 
reply
    Bookmark Topic Watch Topic
  • New Topic