View Full Version : [FRAGE] - kompilieren geht, ausführen nicht...
hab gerade mal zum testen ein kleines HelloWorld probiert zu schreiben, kompilieren und auszuführen. die ersten beiden gehn, ausführen nicht.
1. Datei erstellen:
emacs Hello.java[/java]
2. Sourcecode schreiben.
[code]class Hello
{
public static void main ( String[] args )
{
System.out.println("Hello World!");
}
}
3. speichern
4. kompilieren
javac Hello.java
5. ausführen
java Hello.class
und hierbei krieg ich folgenden fehler:
Exception in thread "main" java.lang.NoClassDefFoundError: Hello/class
im sourcecode sollte eigentlich kein fehler sein da er ja kompiliert wird (und ich ihn von ner seite im netz hab...)
falls den fehler wer kennt, bitte um antwort, sonnst hab ich noch ein semester zeit draufzukommen..... danke *G*
greez
Liquid
dann krieg ich folgende Fehlermeldung:
xception in thread "main" java.lang.UnsupportedClassVersionError: Hello (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(Secure ClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader .java:251)
at java.net.URLClassLoader.access$100(URLClassLoader. java:55)
at java.net.URLClassLoader$1.run(URLClassLoader.java: 194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.j ava:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:2 89)
at sun.misc.Launcher$AppClassLoader.loadClass(Launche r.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:2 35)
at java.lang.ClassLoader.loadClassInternal(ClassLoade r.java:302)
also geh ich mal davon aus dass es "java Hello.class" heisst
greets
liquid
nein es heißt definitiv "java Hello".
Path und Classpath richtig gesetzt? siehe auch hier (http://www.informatik-forum.at/showthread.php?t=3605)
gelbasack
05-01-2005, 17:28
also geh ich mal davon aus dass es "java Hello.class" heisst
Es heißt aber "java Hello".
Dein Sourcecode ist okay.
Sieht nach fehlerhafter Java Installation aus.
Unsupported major.minor version 49.0
das sieht für mich nach einem veralteten java compiler aus
das sieht für mich nach einem veralteten java compiler aus
Das bringt mich auf eine Frage, die mich schon eine Weile beschäftigt. Wie finde ich die javac-version raus? Beim Interpreter ist's leicht:
rck@keds1:~> java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
rck@keds1:~>
Und beim Compiler? Gibt's da wirklich keine Option? Oft genug sind mehrere JDKs installiert und ich wüsste da dann gerne, welche tatsächlich verwendet wird...
rck@keds1:~> javac -help
Usage: javac <options> <source files>
where possible options include:
-g Generate all debugging info
-g:none Generate no debugging info
-g:{lines,vars,source} Generate only some debugging info
-nowarn Generate no warnings
-verbose Output messages about what the compiler is doing
-deprecation Output source locations where deprecated APIs are used
-classpath <path> Specify where to find user class files
-sourcepath <path> Specify where to find input source files
-bootclasspath <path> Override location of bootstrap class files
-extdirs <dirs> Override location of installed extensions
-d <directory> Specify where to place generated class files
-encoding <encoding> Specify character encoding used by source files
-source <release> Provide source compatibility with specified release
-target <release> Generate class files for specific VM version
-help Print a synopsis of standard options
rck@keds1:~>
(Unsupported major.minor version 49.0)
Kann es sein, dass Dein JDK aktueller als Deine JRE ist? Sprich: Neuer Compiler (javac), alter Interpreter (java)? Ich hab zwar keinen Plan, wie man das elegant rausfindet (siehe voriges Posting). Aber unter Linux hilft folgender Trick:
1. Rausfinden, wo die beiden Kollegen sich befinden:
rck@keds1:~> which javac
/usr/lib/java/bin/javac
rck@keds1:~> which java
/usr/lib/java/bin/java
rck@keds1:~>
2. Schauen, ob das eh die binaries sind, oder nicht vielleicht doch nur skripts?
"$(bla)" wird übrigens von der Shell durch das Ergebnis von Program bla ersetzt.
rck@keds1:~> file $(which javac)
/usr/lib/java/bin/javac: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
rck@keds1:~> file $(which java)
/usr/lib/java/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
rck@keds1:~>
3. Das Datum der Datei ansehen. Das ist nicht wirklich elegant und auch nicht 100%ig sicher, sollte aber eine verwertbare Information ergeben:
rck@keds1:~> ls -lad $(which javac)
-rwxr-xr-x 1 root root 25732 Sep 23 2003 /usr/lib/java/bin/javac
rck@keds1:~> ls -lad $(which java)
-rwxr-xr-x 1 root root 24564 Sep 23 2003 /usr/lib/java/bin/java
rck@keds1:~>
In meinem haben beide Dateien das gleiche Datum und somit vermutlich die gleiche Version -- sollte passen. Und in Deinem Fall?
Paulchen
06-01-2005, 10:43
wenn ich "javac -version" eingebe, kommt zwar genauso, als hätte ich javac ohne parameter gestartet, eine lange liste mit den verfügbaren optionen, aber ganz oben steht zusätzlich "javac 1.5.0".
wenn ich "javac -version" eingebe, kommt zwar genauso, als hätte ich javac ohne parameter gestartet, eine lange liste mit den verfügbaren optionen, aber ganz oben steht zusätzlich "javac 1.5.0".
Sun lernt dazu :-)
Hi!
also erstmals danke für die zahlreichen Antworten.
Mittlerweile hab ich das problem in den Griff bekommen und wie einige von euch richtig erkannt haben: verschiedene Java-versionen.
Ich hatte die JRE mittels Yast in Version 1.4.X und JAVA in Version 1.5 als bin oda tar.gz (weiss nimma) von Sun installiert. Das hat einige Verwirrung gestifftet vermut ich mal....
Gelöst hab ich das Problem jetz so, dass ich die Java 1.4 über yast nachinstalliert habe. Die Version 1.5 hab ich "deaktiviert" (dir umbenannt damit nix mehr drauf zugreift und so) und hab die Pfad-Variablen manuell im .bashrc eingetragen.
sieht dann so aus:
export JAVA_BINDIR=/usr/lib/SunJava2-1.4.2/bin
export JAVA_HOME=/usr/lib/SunJava2-1.4.2
export JAVA_ROOT=/usr/lib/SunJava2-1.4.2
export JRE_HOME=/usr/lib/SunJava2-1.4.2/jre
danach hatte ich immer noch das Problem dass javac nicht gefunden wurde. Dem hab ich abhilfe besorgt indem ich die Zeile
export PATH=$PATH:/usr/lib/SunJava2-1.4.2/bin
(auch in .bashrc) angefügt hab
Das in meinem anderen thread beschriebene Problem mit der EprogIO hab ich gelöst indem ich wie bei den anderen problemchen einen Eintrag in der .bashrc gemacht habe, der beim Classpath den ordner der EprogIO anfügt. sollte funktionieren hoffe ich.
export CLASSPATH=$CLASSPATH:/home/florian/Eprog/EprogIO
Danke nochmal für die Hilfe
Hoffe dass meine Problemlösung mal jemandem anderen hilft
lg
Liquid
"Windows zu Linux sind wie herkömmliche Fortpflanzung zur Gentechnik...
Linux funktioniert, ist kontrollierbar aba kein schwein kennt sich aus , Windows kann jeder, dafür weiss keiner was für ein scheiss dabei rauskommt...."
Zitat: Ich nach 5h Linux&Java Troubleshooting...
vBulletin® v3.7.1, Copyright ©2000-2009, Jelsoft Enterprises Ltd.