JDK-6707036 : VM launcher should better describe supported classfile versions
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-05-26
  • Updated: 2014-03-07
  • Resolved: 2014-03-07
Related Reports
Duplicate :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
This error message occurs when a JVM attempts to run bytecode compiled by a new version of Java.  It should say that.  In addition, either the "major.minor" version should be included by 'java -version', or don't include it in the error message.

JUSTIFICATION :
There is no easy way to correlate a major.minor version to a Java VM version.  The existing error message is unnecessarily confusing, and generates lots of Google searches, or worse: casual users will just abandon the attempt to run the app, and probably leave with a sour taste in their mouth regarding Java in general.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would like to see a more informative, useful message like:

"This Java program appears to be compiled by a version of Java newer than what this version (JVM 1.x) can support.  Please upgrade your Java version, or recompile with -target 1.x."
ACTUAL -


C:\>appletviewer JMFAudioLoop.java
java.lang.UnsupportedClassVersionError: JMFAudioLoop (Unsupported major.minor version 49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:157)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:123)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:561)
at sun.applet.AppletPanel.createApplet(AppletPanel.java:617)
at sun.applet.AppletPanel.runLoader(AppletPanel.java:546)
at sun.applet.AppletPanel.run(AppletPanel.java:298)
at java.lang.Thread.run(Thread.java:534)


---------- BEGIN SOURCE ----------
Compile any application with a new JDK, then run with an older JRE.
---------- END SOURCE ----------

Comments
RT Triage team: The JDK-8016644 will address this issue
07-03-2014

EVALUATION Everything that is ever likely to be written about ClassFile versioning, is written here: http://blogs.sun.com/abuckley/en_US/entry/versioning_in_the_java_platform http://blogs.sun.com/darcy/entry/source_target_class_file_version This RFE was never really about the spec, so I'm refiling it for the Hotspot impl to consider.
19-08-2009

EVALUATION The mapping of Java SE version to classfile version is properly the responsibility of the SE Platform Spec. The JVMS3 draft says: Sun���s Java virtual machine implementation in JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. JDK releases 1.1.X support class file format versions in the range 45.0 through 45.65535 inclusive. For k>=2, implementations of version 1.k of the Java platform support class file format versions in the range 45.0 through 44+k.0 inclusive. giving 1.4 -> 48.0, 1.5 -> 49.0, 1.6 -> 50.0 In addition, the default -source and -target flags for javac in a given SE version should be documented. In JDK1.6/SE 6, the default -source is 1.5, which implies a default -target of 1.5. javac uses the command line -source flag to determine whether to recognize attributes in class files; it does *not* appear to use the version number of each class file.
27-05-2008