Bug 1040082

Summary:	java.lang.UnsupportedClassVersionError: ... : Unsupported major.minor version 51.0
Product:	Red Hat Enterprise Linux 5	Reporter:	crossfire2003
Component:	java-1.6.0-openjdk	Assignee:	Deepak Bhole <dbhole>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	5.11
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-17 21:15:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description crossfire2003 2013-12-10 16:48:42 UTC

Description of problem:

When a user tries to run Java code that was not compiled for the currently set jre version a ugly stack trace is shown:

java.lang.UnsupportedClassVersionError: ... : Unsupported major.minor version 51.0
...

Whenever something like this happens in our software, we tell our users. This is a bug, we need to fix it.

I would expect a message like: You are running the wrong Java version on this machine: 1.6, please install and set the right java version: 1.7

A normal user will first have to find out what a major.minor version is, then have to find the mapping between majaor.minor and Java version, depending on vendor, this  could even vary. This is not a good user experience.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. Install and set java 6: java -version should show 1.6
2. Run Java 7 compiled code against this java version


Actual results:
java.lang.UnsupportedClassVersionError: ... : Unsupported major.minor version 51.0

Expected results:
You are running the wrong Java version on this machine: 1.6, please install and set the right java version: 1.7

Additional info:

Comment 1 Deepak Bhole 2013-12-10 19:31:13 UTC

The UnsupportedClassVersionError message has been standard for many years now. I don't think changing it is viable since there could easily be scripts that attempt to parse that message and take appropriate action.

The suggested way of fixing this would be to either compile the application with Java 6 ('-source 6 -target 6') or compile the main class with it and have it show a relevant message if it does not detect Java 7 running. If the application is compiled with 6 and it is 3rd party libraries that cause the issue, there should be a catch for java.lang.UnsupportedClassVersionError in the loader code that shows the appropriate message.

As for the mapping, the major/minor version mapping is not vendor dependent AFAIK -- class file versions need to be consistent to ensure that the compiled bytecode can run on any vendor's JVM.

If there are no further objections, I will close this issue as WONTFIX in a week.