-3

I have to develop a GUI for a dedicated piece of hardware that runs Debian. So, I got an example of the hardware it will run on, I installed the most current JRE (since it doesn't come with much installed), moved my code over from my development environment on a not-too-old Fedora-Core box, launched the app and got:

Exception in thread "main" java.lang.UnsupportedClassVersionError: mygui/MYGUI : Unsupported major.minor version 52.0

Thinking this odd, I did the typical yum update, then a build and got the same thing... So, deciding to just do the build on the new box itself, I installed the JDK. I then did a build using the newly installed JDK, which went fine but for one file - my-bad on a file-name / class-name mismatch - so I fixed it, and re-did the compile of just the one file and got:

warning: /opt/mygui/lib/fubar.class: major version 52 is newer
than 51, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.
1 warning

This tells me that the compiler itself must have a bug! All it's looking at is the files it itself had just built! A team-mate suggested I remove the JRE, but I don't see how that helps since the compiler itself must have mislabeled the output.

Before you ask:

# javac -version
javac 1.7.0_111
# java -version
java version "1.7.0_111"
OpenJDK Runtime Environment (IcedTea 2.6.7) (7u111-2.6.7-1~deb8u1)
OpenJDK Zero VM (build 24.111-b01, interpreted mode)

I'm thinking someone else has seen this - anyone?

NOT DONE YET, seeing as that the compiler had only given a warning, I went to run it. The initial frame came up fine and I figured it was all fixed! YAY! But then I tried clicking on a menu item that brings up a new frame and instead of success, the new frame did NOT start and at the top of the error message dump I got:

Exception in thread "AWT-EventQueue-0"
java.lang.UnsupportedClassVersionError: mygui/secondframe : Unsupported
major.minor version 52.0

OK, so "it's broke." Anyone?

(NOTE: I found this other, similar question, but it's clearly different from my scenario.)

UPDATE: OK, fine, I already get it that the Java THINKS it has a version mismatch. People who are focusing on that are focusing on the wrong problem. The problem is "how the hell can it possibly think it's the wrong version? And, more importantly, what the hell do I do about it?!"

UPDATE TWO: At the suggestion of Laksitha Ranasingha (below), I ran the javap command he recommended and the answer was:

$ javap -v mygui.MYGUI | grep major
  major version: 51

So, this goes to show that there's a bug with both the JDK and the "java" runtime environment (whether it came from the JRE I installed or the JDK I installed afterward, I don't actually know). For some reason BOTH the javac and java programs that are trying to either do more compiles of parts of the same package or run the package are getting errant data.

UPDATE THREE: I really don't care what the version is, and there are no outside libraries or apps. It was ALL - and I mean all of it - compiled by this same version. The ONLY reason "version 7" is involved is because the hardware vendor pointed me / us / their customers at it. Here's their product, released March, basically one year ago:

TS-7970

Here's where they tell us how to add Java. In sum, they say run:

# apt-cache search openjdk

Then pick the youngest one and then run:

# apt-get install openjdk-7-jre

I did that and later did:

# apt-get install openjdk-7-jdk

And then AFTER all this started, I did - and got:

# apt-get install openjdk-8-jdk

Package openjdk-8-jdk is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

I take it then that there is no version 8 available.

...SO... MAYBE I have to remove all this and install the package some other way. But how? It's not a powerful box. Compiles that take seconds on my dev system take over 20 minutes on this thing...

Fourth and maybe FINAL update: ...I think this question better belongs on either the ServerFault forum or perhaps the SuperUser forum since it's not a programming problem. I guess I'm old school, been here from the early days of this site when this was the only forum. But the down-votes are just a clue. Question is, I've seen questions "migrated" between forums but don't know how to do it. If anyone cares to comment how that can be done, it might make the people here happier they don't have to deal with non-programming problems while improving my odds. Or, I can just re-enter it.

Richard T
  • 4,570
  • 5
  • 37
  • 49
  • Yes. You've got classes compiled with Java 8. You need to upgrade to Java 8. You won't be getting it to work with Java 7. – Elliott Frisch Mar 22 '18 at 23:47
  • @ElliottFrisch Sorry, Elliot, you lost me there. I don't give a flying fish WHAT version; it's THE SAME COMPILER _and_ SAME RUN TIME ENVIRONMENT. So, what are you saying? HOW is it that I have "the wrong version"? Besides, it's on the youngest version available, so far as I am aware. If I'm missing it, you need to explain _clearly._ Otherwise, looks like a bug to me. – Richard T Mar 22 '18 at 23:51
  • 2
    The error message "java.lang.UnsupportedClassVersionError: mygui/MYGUI : Unsupported major.minor version 52.0" says that "mygui/MYGUI" is compiled with Java 8. You cannot run code that depends on any class compiled with Java 8 on Java 7. That error says that regardless of what you SAY / THINK / ASSERT, it was compiled with Java 8. You will not get that error any other way. – Elliott Frisch Mar 22 '18 at 23:57
  • @ElliottFrisch OK, fine; how the hell is _that_ helpful? I think it's a compiler bug, labeling code it _just_created_ as lower than the version it should be - just a guess. OR, put another way, how the hell did it create any Java 8 code when it claims to be a version 7 compiler? – Richard T Mar 22 '18 at 23:59
  • 3
    Do you realize the people here are *volunteers*? Comments like the above are really not necessary. – Rob Mar 23 '18 at 00:07
  • @Rob Thanks Rob, I think the multiple-down-votes and close-vote with NO indications why just pissed me off. Whoever these people are aren't paying attention to the actual problem. Why is this a bad question? – Richard T Mar 23 '18 at 00:11
  • Do you depend on any third party classes? Java 7 has been [eol](https://java.com/en/download/faq/java_7.xml) since **April** of **2015**. That was three years ago. – Elliott Frisch Mar 23 '18 at 00:19
  • @ElliotFrisch No, Elliot, it's clean. NO third party classes. Note that I don't care at all what the Java version is. This is so modest it would probably compile with Java 1.4. The ONLY involvement of 7 is just what I was provided by the hardware vendor as the most current available. The code should work with this version, no problem. I figured compiling it all on the same compiler would solve any mis-match problem. (I'll update the question with more about the installation process.) – Richard T Mar 23 '18 at 00:27
  • @pikachu0 Okay and fine; main focus is on which class OP has that is major 52; the fact that he can't get public support from Oracle is relevant in that people have moved on - and some logger, apache utility, etc is clearly on the CLASSPATH and compiled against Java 8. – Elliott Frisch Mar 23 '18 at 00:50
  • @ElliottFrisch You write, "main focus is on which class OP has that is major 52 [...] and some logger, apache utility, etc is clearly on the CLASSPATH and compiled against Java 8." (sorry for the all caps) EXCEPT THAT THERE IS NO SUCH CONTENT. One hundred percent of _everything_ in CLASSPATH was built by _this_ compiler. Seriously. THAT is the problem! There's NOTHING there that wasn't built by this compiler. – Richard T Mar 23 '18 at 00:54

2 Answers2

1

You are trying to run Java 8 compiled app on Java 7 which is not possible. you can check your class version using:

javap -v fubar.class | grep major

Even setting -source and -target won't work. You need to compile sources in Java 7 (if you don't use Java 8 features) or upgrade the JRE to Java 8. This Oracle documentation describes how class versions are determined. https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html

Sourced from Wikipedia, the version numbering goes as:

Java SE 10 = 54 (0x36 hex),[3]
Java SE 9 = 53 (0x35 hex),[4]
Java SE 8 = 52 (0x34 hex),
Java SE 7 = 51 (0x33 hex),
Java SE 6.0 = 50 (0x32 hex),
Java SE 5.0 = 49 (0x31 hex),
JDK 1.4 = 48 (0x30 hex),
JDK 1.3 = 47 (0x2F hex),
JDK 1.2 = 46 (0x2E hex),
JDK 1.1 = 45 (0x2D hex)

This answer will also help.

Laksitha Ranasingha
  • 4,321
  • 1
  • 28
  • 33
  • Thanks for the attempt, but the question isn't why is there an error message, it's how can a version 7 compiler create code it itself isn't happy with and won't run? BUG! Right? Please focus on the REAL problem, the installation. Assuming it was a problem I created is just not paying attention. PLEASE note that the SAME compiler was involved in creating ALL the class files AND is the same version as the java program that would read the class files. THERE ARE NO OTHER FILES INVOLVED. I DID NOT MIX AND MATCH VERSIONS! – Richard T Mar 23 '18 at 00:09
  • 1
    Before thinking about a bug in javac, what have you got after running javap command? the answer is trying to give you a solution not to talk about the error message. – Laksitha Ranasingha Mar 23 '18 at 00:11
  • Thanks LR, it says "major version: 51". – Richard T Mar 23 '18 at 00:16
  • No Problem. As per your UPDATE 2, you are pointing to a different class now (m16gui.M16GUI). But the exception apparently occurred on mygui/secondframe class. wasn't it? I'm curious. – Laksitha Ranasingha Mar 23 '18 at 00:31
  • **And** `/opt/mygui/lib/fubar.class` - what was that? – Elliott Frisch Mar 23 '18 at 00:32
  • @ElliottFrisch Those were oopses, trying to hide customer data that doesn't belong here. Nice if you edit it out too. :-) – Richard T Mar 23 '18 at 00:39
-1

Well, it turned out to be an installation problem.

A key clue was this:

# apt-get install openjdk-8-jdk

Package openjdk-8-jdk is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

Since NONE of the class files available were from anything but what was created by this compiler, and since none of the other comments or answers paid any attention to installation issues, I decided that this was a likely avenue to pursue.

So, my thinking was that this line, in particular, was key:

Package openjdk-8-jdk is not available, but is referred to by another package.

So, I deleted everything related to Java and did a reinstallation of just the JDK. I also deleted the whole of what had been built before and was left with just the source java files, and then did a fresh compile of everything.

To my delight, this worked.

(All those who down-voted and were otherwise negative need to reconsider their viewpoint. Installation problems are real and aren't necessarily the fault of the person doing the work. Installation bugs happen, too.)

Richard T
  • 4,570
  • 5
  • 37
  • 49