nicht angemeldet
Compilier-Fehler
also, hab ne .java-Datei, die ich versuche mit javac zu compilieren.... jaja, ich weiss, RTFM... hab ich ja auch getan, bekomme aber beim compilieren einen haufen Fehlermeldungen.
Zunaechst muss ich gestehen, hab ich von Java nicht soviel Ahnung.
1. Wie gibt man den Pfad der .class-Dateien bei import an?
Momentan steht das da: import gnu.regexp.*;
In meinem Ordner gibt es ein Verzeichnis "gnu" und darin ein Verzeichnis namens "regexp". Muesste doch gehen oder?
Daran hab ich mich aber nicht lang aufgehalten und hab einfach die .class-Dateien in das Verzeichnis der .java-Datei kopiert und das import auskommentiert.
Nun bekomme ich folgende Fehlermeldungen:
- cannot resolve symbol symbol : class RE location class 1
RE ex = new RE("[1]*$");
^
- warning: getHours() in java.util.Date has been deprecated
usw...
2. Was ist also damit gemeint? Wie kann ichs abschalten?
A-Za-z0-9 ↩︎
-
Hallo qua,
In meinem Ordner gibt es ein Verzeichnis "gnu" und darin ein Verzeichnis namens "regexp". Muesste doch gehen oder?
Wenn die Klassen wirklich im Paket gnu.regexp liegen und das Verzeichnis im Classpath ist, dann sollte es gehen, ja.
Ich vermute aber, dass das Paket org.gnu.regexp heißt, da das die übliche Bezeichnung wäre.Daran hab ich mich aber nicht lang aufgehalten und hab einfach die .class-Dateien in das Verzeichnis der .java-Datei kopiert und das import auskommentiert.
Du kannst Classdateien nicht einfach in irgend ein Verzeichnis kopieren. Klassen enthalten die Information, zu welchem Paktet sie gehören. Damit muss die Verzeichnisstruktur übereinstimmen.
- warning: getHours() in java.util.Date has been deprecated
usw...Date ist depecated, d.h. es sollte nicht mehr benutzt werden.
Die Klasse wurde durch Callendar ersetzt.Grüße
Daniel
-
Hallo Daniel,
vielen Dank fuer Deine Antwort.In meinem Ordner gibt es ein Verzeichnis "gnu" und darin ein Verzeichnis namens "regexp". Muesste doch gehen oder?
Wenn die Klassen wirklich im Paket gnu.regexp liegen und das Verzeichnis im Classpath ist, dann sollte es gehen, ja.
Ich vermute aber, dass das Paket org.gnu.regexp heißt, da das die übliche Bezeichnung wäre.Nee, eigentlich nicht. Verzeichnisbaum:
src
*.java
gnu
regexp
*.class
Aber so bringt er mir, oben beschriebenen Fehler.Du kannst Classdateien nicht einfach in irgend ein Verzeichnis kopieren. Klassen enthalten die Information, zu welchem Paktet sie gehören. Damit muss die Verzeichnisstruktur übereinstimmen.
Ich sag doch, ich bin ein n00b. Also woran liegt das dann, wenn ich den oben beschriebenen Fehler (unter 1.) bekomm?
- warning: getHours() in java.util.Date has been deprecated
usw...
Date ist depecated, d.h. es sollte nicht mehr benutzt werden.
Die Klasse wurde durch Callendar ersetzt.Okay... Das sollte sich im Manual finden lassen... Oder wenn ich meine getHours weiterhin einsetzen will, heisst das einfach eine aeltere java-Distribution drueber spielen?
Omg, sowas vor Weihnachten. Erwaehnte ich schon, dass ich Weihnachten nicht sonderlich mag?
Danke, wenn jmd antworten mag, wuerde mir das sehr weiterhelfen...Gruss das q
-
Nachtrag:
Hab mal die nicht mehr von sun supportete(!!) Version 1.2.2 installiert und total andere Fehlermeldungen bekommen.
package gnu.regexp does not exist...
cannot resolve symbol...
usw. Meine API-Version scheint auch abgelaufen zu sein(??).. Also irgendwas mach ich falsch. Mag mir mal wer auf die Spruenge helfen, bitte?
Gruss
q -
Hallo qua,
Nee, eigentlich nicht.
Bist Du Dir da sicher? Hast Du in der Dokumentation geguckt, wie das Paket heißt? Ich konnte die auf die Schnelle auf gnu.org nicht finden.
src
*.java
gnu
regexp
*.classVersuch mal, beim Kompilieren -cp . anzugeben.
Okay... Das sollte sich im Manual finden lassen... Oder wenn ich meine getHours weiterhin einsetzen will, heisst das einfach eine aeltere java-Distribution drueber spielen?
Nein, Du kannst die Problemlos weiterhin verwenden. Die Klasse hat nur Nachteile, so unterstüzt sie z.B. keine Zeitzohnen und wird auch nicht mehr irgendwie weiterentwickelt werden.
Man erspaart sich im Allgemeinen ärger, wenn man keine veralteten Klassen oder Methoden verwendet.
Der Complier gibt ja auch nur eine Warnung aus. Das ist kein Fehler, er weißt Dich nur darauf hin, das Du Dir überlegen solltest, ob Du das wirklich so machen willst.Grüße
Daniel
-
Bist Du Dir da sicher? Hast Du in der Dokumentation geguckt, wie das Paket heißt? Ich konnte die auf die Schnelle auf gnu.org nicht finden.
Kannst du auch nicht. Der Pfad, in dem die .class liegen, heisst so....
Ich dachte, da waer ein Unterschied?Versuch mal, beim Kompilieren -cp . anzugeben.
-cp is an invalid option or argument
Nein, Du kannst die Problemlos weiterhin verwenden. Die Klasse hat nur Nachteile, so unterstüzt sie z.B. keine Zeitzohnen und wird auch nicht mehr irgendwie weiterentwickelt werden.
Man erspaart sich im Allgemeinen ärger, wenn man keine veralteten Klassen oder Methoden verwendet.
Der Complier gibt ja auch nur eine Warnung aus. Das ist kein Fehler, er weißt Dich nur darauf hin, das Du Dir überlegen solltest, ob Du das wirklich so machen willst.Ja, super. Sag mir das, bevor ich mir die alte Version runterlade und installiere -g-
Nungut. Ich geh jetzt in meinen Urlaub. Am Mittwoch mach ich weiter. Wenn sich jmd bis dahin was einfallen lassen mag? Waer sehr dankbar.
Frohes Fest usw...Gruss q
-
Hallo qua,
Kannst du auch nicht. Der Pfad, in dem die .class liegen, heisst so....
Ich dachte, da waer ein Unterschied?Nein, die Verzeichnisstruktur muss genau den Paketnamen entsprechen.
Was Du angeben kannst, ist das Verzeichnis, indem diese Verzeichnisstruktur mit den Klassen liegt. Das ist das, was man als Classpath bezeichnet.
Das import-Statement hat damit nichts zu tun, das bezieht sich nur auf den Paketnamen. Wo genau die Klassen liegen, kann man daraus nicht ableiten.Versuch mal, beim Kompilieren -cp . anzugeben.
-cp is an invalid option or argumentjavac hat ganz sicher diese Option.
Ja, super. Sag mir das, bevor ich mir die alte Version runterlade und installiere -g-
Hab ich gesagt, dass Du das tun sollst? ;-)
Grüße
Daniel
-
-
-
-