3

I am trying to compile Java code, with Sun Java JDK 1.7.0_17, on a Linux Mint system, but I'm getting this problem.

$ javac  -version -target 1.7 
javac 1.7.0_17
javac: invalid target release: 1.7

-target 1.6 doesn't work either. Target 1.5 works, but I get a version problem as such,

$ javac  -version -target 1.5 HelloWorld.java 
javac 1.7.0_17
HelloWorld.java:2: cannot access java.lang.Object
bad class file: /usr/lib/jvm/jdk1.7.0_17/jre/lib/rt.jar(java/lang/Object.class)
class file has wrong version 51.0, should be 49.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
class HelloWorldApp {
^
1 error

Is there somewhere a list of available java targets outside of the sun java directories?

I have no ClassPath or Javahome specified, and setting them doesn't help. jcontrol doesn't help. I have also tried with 1.7.0_15, with similar results.

Serge Ivanoff
  • 184
  • 1
  • 5

4 Answers4

5

I chased down a similar issue involving Ubuntu, Netbeans and two JDK's: openJDK and oracleJDK. The offending (old and irrelevant) files were eventually located in /usr/java/packages and simply deleted.

I was receiving:

# javac -version hello.java
javac 1.7.0_21
hello.java:3: cannot access java.lang.Object
bad class file: /usr/lib/jvm/java-7-oracle/jre/lib/rt.jar(java/lang/Object.class)
class file has wrong version 51.0, should be 49.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
public class hello {
       ^
1 error

More importantly, I located the offending files with:

# javac -verbose -version hello.java

The -verbose option lists the search path for class files.

Other areas explored during my investigation were:

  • the value of environment variable JAVA_HOME with #echo $JAVA_HOME
  • the value of environment variable PATH with #echo $JAVA_HOME
  • the value of environment variable CLASSPATH with #echo $JAVA_HOME
  • the update-alternatives with #update-alternatives --config javac
  • the update-alternatives with #galternatives
  • the JDK used by Netbeans set in /usr/local/netbeans-7.3/etc/netbeans.conf with the netbeans_jdkhome= switch. Note that this switch overrides update-alternatives
nhoj
  • 135
  • 2
  • 11
  • Oh, but that was sooo close. I found, just as you predicted, some old jar files being picked up from the _/usr/java/packages/lib/ext_ directory. By removing them, it took them out of the **-verbose** listings, but otherwise had no effect. I still get the wrong version error. – Serge Ivanoff Apr 20 '13 at 11:39
  • I wonder if [versioncheck](https://code.google.com/p/versioncheck/) might help you track down the offending jar? – nhoj Apr 20 '13 at 17:52
  • I just tried VersionChecker, and it didn't seem to help, other than the 1.7 Java Compatibility being blank, `Major.Minor Version : 51.0 JAVA compatibility : `. Seeing as the web pages only refer up to 1.6, I'm guessing that it hasn't been rebuilt for jdk7, rather than my problem – Serge Ivanoff Apr 22 '13 at 01:06
  • Thank you so much I was having the same problem for sometime affected javah and ant, wasted so much time look for a solution. After moving all the files out out /usr/java/packages/lib/ext compiled a simple file and it worked fine. That directory was filled with these files from installing this is Australian Business Govt App – pt123 Aug 07 '13 at 09:31
0

I was able to compile a file just fine. I CDed into the directory of the file, then ran 

javac -version -target 1.7 App.java

(App.java is the file name).

I was able to run javac -version and it gave me back:

javac 1.7.0_17

So clearly it knows which version of Java I'm using.

If I run what you did though:

javac -version -target 1.7

I get the exact same message as I do if I run only javac -version:

javac 1.7.0_17

So it seems that running -version and -target 1.7 means that the -target 1.7 gets ignored.

I do have JAVA_HOME specified.

Why do you need to specify -target 1.7 anyway? That should be the default if you're using 1.7.

In your first source code post, did you mean to say "javac HelloWorld.java"? Because that should be the command I would think you would want to run. Not "javac -version -target 1.7".

CorayThan
  • 17,174
  • 28
  • 113
  • 161
  • I don't need to specify (well, shouldn't need to). If I don't specify, it defaults to using 1.5, which gives me the _wrong version_ error. – Serge Ivanoff Mar 13 '13 at 05:26
  • Don't some linux systems come pre-installed with a version of Java? Maybe that version of java is trumping the one you've installed? – CorayThan Mar 13 '13 at 05:29
  • I thought so, too. Originally, Mint installed OpenJDK 1.7 and 1.6. Never had 1.5 (neither JDK or JRE). I blew both away and installed Sun 1.7.0_15 and now _17. Neither work. – Serge Ivanoff Mar 13 '13 at 05:36
  • Afraid I'm not a linux expert and it sounds like your issue isn't with your commands to the compiler. Sorry! – CorayThan Mar 13 '13 at 05:49
0

Update: I reinstalled Mint and the problem went away. Not my preferred option, I should say.

I've yet to compare the differences between the systems.

Can anyone think of how a 1.7 compiler won't build 1.7 code?

Serge Ivanoff
  • 184
  • 1
  • 5
0

Diagnostics:

You can see which java version Maven uses by running "mvn --version"

Solution for Debian:

The mvn script sets the JAVA_HOME env variable internally by looking for javac (which javac). Therefore, if you have multiple java versions installed concurrently, e.g. JDK 6 and JDK 7 and use the Debian Alternatives system to choose between them, even though you changed the alternative for "java" to JDK 7, mvn will still use JDK 6. You have to change the alternative for "javac", too. E.g.:

# update-alternatives --set javac /usr/lib/jvm/java-7-openjdk-amd64/bin/javac
user323094
  • 3,643
  • 4
  • 21
  • 30