Umstellung von Java6 auf 5 - @Override ist nun ein Fehler!

Status
Nicht offen für weitere Antworten.
T

Tarmack

Gast
Hi,

Ich habe in Eclipse den Compiler von Java6 auf 5 umgestellt (neustes JDK). Nun sagt er mit bei jeder Klasse wo ich ein Interface implementiere und eine Methode ein @Override hat:


Multiple markers at this line
- The method actionPerformed(ActionEvent) of type UndoRedoManager.CloneAction must override a superclass
method
- implements java.awt.event.ActionListener.actionPerformed


Was ist da los? Geht die @Override Annotation wirklich nicht in Java5? Ich kann jetzt schlecht jedes @Override entfernen, will das auch nicht :(
 
S

SlaterB

Gast
in meinen Augen ist das Implementieren eines Interfaces auch kein Override,
das hat sich wohl zwischen 1.5 und 1.6 geändert,

wieso geht das Entfernen schlecht?
stell dir vor du hättest auf 1.4 umgestellt, was du da alles hätttest ändern müssen..,

einfach so Comiler zurückdrehen ohne Konsequencen, das geht doch viel eher nicht
 
G

Guest

Gast
SlaterB hat gesagt.:
in meinen Augen ist das Implementieren eines Interfaces auch kein Override,
das hat sich wohl zwischen 1.5 und 1.6 geändert,

wieso geht das Entfernen schlecht?
stell dir vor du hättest auf 1.4 umgestellt, was du da alles hätttest ändern müssen..,

einfach so Comiler zurückdrehen ohne Konsequencen, das geht doch viel eher nicht

Kann vielleicht jemand reproduzieren was ich da berichte - vielleicht mach ich ja einen anderen Fehler und merke es nicht.
 
B

Beni

Gast
Du machst keinen Fehler, es ist so. Vielleicht kannst du Eclipse in den Einstellungen sagen, dass die Override-Annotation ignoriert werden soll (irgendwo bei den Compiler-Einstellungen dürfte das sein).
[Edit: such mal in "Java > Compiler > Errors/Warnings"]

Mir hätte eine Annotation "@implements" für Interfaces besser gefallen.
 

musiKk

Top Contributor
Ich kann das reproduzieren. Auf 1.5 gestellt, gibt das einen Fehler. Offenbar wurde das wirklich mit dem Versionssprung auf 1.6 geaendert. So richtig nachvollziehen kann ichs allerdings nicht. Wenn ein Interface implementiert wird, gibt es doch ganz andere Kontrollmechanismen, ob die Methoden implementiert werden. Sieht leider so aus, als muesstest du damit leben.
 
G

Guest

Gast
Beni hat gesagt.:
Du machst keinen Fehler, es ist so. Vielleicht kannst du Eclipse in den Einstellungen sagen, dass die Override-Annotation ignoriert werden soll (irgendwo bei den Compiler-Einstellungen dürfte das sein).
[Edit: such mal in "Java > Compiler > Errors/Warnings"]

Mir hätte eine Annotation "@implements" für Interfaces besser gefallen.

Ich kann das Compiler Compliance Level auf 1.6 stellen. So wird das PRoblem ignoriert. Ist @Override eine Annotation die beim Compilerien entfernt wird? Sollte der Code also auf einer JVM5 laufen?

nee er sagt mir: java.lang.UnsupportedClassVersionError: Bad version number in .class file


Sollte ich also @Override komplett entfernen oder durch irgendwas ersetzen? @implements?
 
B

Beni

Gast
Wenn du in 1.5 entwickelst, dann musst du @Override wohl entfernen (ausgenommen bei den Methoden, die tatsächlich etwas überschreiben).
 
G

Guest

Gast
Beni hat gesagt.:
Wenn du in 1.5 entwickelst, dann musst du @Override wohl entfernen (ausgenommen bei den Methoden, die tatsächlich etwas überschreiben).

Na supi. Dann dachte ich schon ich koennte es automatisch machen :(

Wer das mit dem @Override verbrochen hat gehoert gefoltert :(


Weiss irgendwer Genaueres? Vielleicht gibt es ja einen triftigen Grund fuer dieses @Override Desaster?
 
M

maki

Gast
Anonymous hat gesagt.:
Beni hat gesagt.:
Wenn du in 1.5 entwickelst, dann musst du @Override wohl entfernen (ausgenommen bei den Methoden, die tatsächlich etwas überschreiben).

Na supi. Dann dachte ich schon ich koennte es automatisch machen :(

Wer das mit dem @Override verbrochen hat gehoert gefoltert :(


Weiss irgendwer Genaueres? Vielleicht gibt es ja einen triftigen Grund fuer dieses @Override Desaster?
Wer sich nicht über die Unterschiede informiert und trotzdem von einer neueren Vesion auf eine ältere (???) umstellt ist selber schuld ;)

Eine zus. Anno. für "implementents" wollte man wohl vermeiden.
 
G

Guest

Gast
Wer sich nicht über die Unterschiede informiert und trotzdem von einer neueren Vesion auf eine ältere (???) umstellt ist selber schuld ;)

Eine zus. Anno. für "implementents" wollte man wohl vermeiden.

Also bitte!


@Implements haette man ruhig vermeiden koennen.

@Override:

Indicates that a method declaration is intended to override a method declaration in a superclass. If a method is annotated with this annotation type but does not override a superclass method, compilers are required to generate an error message.



Ein Java6 Kompiler koennte also locker Compiler Warnings statt errors ausgeben und trotzdem Java5 conforme .class files erstellen. Auch wenn ich Java5 unterstuetzen will macht es durchaus Sinn die @Override Annos fuer alle Interface Methoden zu haben - da man so Fehler vermeiden kann. Desewegen wurde es ja in Java6 eingefuehrt.

Also eine Schande dass man mit einem 6er Compiler keinen 5er konformen Code erzeugen kann nur weil dieser @Override Annos fuer Interface Methoden mitbringt. Es handelt sich um einen Compiler-Check - sonst nichts!

[/quote]
 

didjitalist

Bekanntes Mitglied
@Implements wäre sehr schnell inkonsistent geworden. Was soll "implementiert" ausdrücken? Das diese Methode nichts überschreibt, sondern implementiert wahrscheinlich. Aber was ist, wenn man eine abstrakte Methode einer abstrakten Klasse "überschreibt"? Das wäre nach der Definition auch ein @Implements. Aber wenn jetzt die Vaterklasse geändert und die Methode konkrekt wird, dann stimmte die annotation nicht mehr.

Finds daher schon ganz OK, auch für interfaces @Override zu verwenden. Dadurch bleibt es konsistent. Und außerdem sind interfaces im Grunde ja auch nur sehr spezielle abstrakte Klassen.
 

didjitalist

Bekanntes Mitglied
Anonymous hat gesagt.:
Ein Java6 Kompiler koennte also locker Compiler Warnings statt errors ausgeben und trotzdem Java5 conforme .class files erstellen.
Dabei setzt du aber voraus, dass der compiler irgendwelche magischen annotations ignorieren darf und andere nicht. Wo soll er da anfangen und wo aufhören? Dass der 6er compiler gültigen 5er code generiert kann man wirklich nur dann garantieren, wenn er sich 100% identisch verhält.
 

ps

Bekanntes Mitglied
Wo ist denn euer Problem? Natürlich kannst du jederzeit mit dem javac von 1.6.0 bytecode erzeugen welcher auf der jvm von 1.5.0 läuft.
Aber ich verstehe auch garnicht wieso du jetzt fehler bekommst. Ich habe ein paar Projekte die ich sowohl zu 1.5.0 als auch zu 1.6.0 compilieren kann... ohne irgendwas zu ändern. Ich benutze @Override immer wenn ich ein Interface implementiere..

Benutze allerdings auch das sun-jdk, nicht den eclipse compiler.

[edit:
habs jetzt rausgefunden - der javac 1.5.0 bringt den fehler. du kannst aber doch jederzeit mit dem javac von 1.6.0 bytecode für ältere versionen erzeugen. das sollte dann auch anstandslos auf der jeweiligen zielplattform laufen. probiert hab ich das aber noch nicht ;) ]
 
G

Guest

Gast
ps hat gesagt.:
Wo ist denn euer Problem? Natürlich kannst du jederzeit mit dem javac von 1.6.0 bytecode erzeugen welcher auf der jvm von 1.5.0 läuft.
Aber ich verstehe auch garnicht wieso du jetzt fehler bekommst. Ich habe ein paar Projekte die ich sowohl zu 1.5.0 als auch zu 1.6.0 compilieren kann... ohne irgendwas zu ändern. Ich benutze @Override immer wenn ich ein Interface implementiere..

Benutze allerdings auch das sun-jdk, nicht den eclipse compiler.

[edit:
habs jetzt rausgefunden - der javac 1.5.0 bringt den fehler. du kannst aber doch jederzeit mit dem javac von 1.6.0 bytecode für ältere versionen erzeugen. das sollte dann auch anstandslos auf der jeweiligen zielplattform laufen. probiert hab ich das aber noch nicht ;) ]

Das geht natuerlich schon. Ich muss halt eben ein Java6 fuer die Compilierung benutzen. Wenn also Java6 Methodenaufrufe verwendet werden beschwert sich der Compiler nicht - Java5 aber waehrend der Laufzeit schon und quittiert es mit einem Absturz.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
S Umstellung von File auf Path - Probleme mit Stream Allgemeine Java-Themen 5
J Jasper Reports - Compilerproblem nach Umstellung von Groovy auf Java Allgemeine Java-Themen 7
F E-Mail aus JAVA senden nach Umstellung auf Netbean 7.4 mit Java 7U45 nicht mehr möglich Allgemeine Java-Themen 4
J Umstellung von double auf BigDecimal Allgemeine Java-Themen 5
A Umstellung eines(riesen)Programmes auf Java:Was bietet Java Allgemeine Java-Themen 18
O Ärger bei Umstellung von 1.4 auf 1.6 Allgemeine Java-Themen 12
M Umstellung auf Java, was kann java? Hardwareunterstützung? Allgemeine Java-Themen 12
S Problem bei Umstellung von (default package) auf Packages Allgemeine Java-Themen 10
W Performanzprobleme mit Java6 Allgemeine Java-Themen 11
T Java6 - Klassen in Java-5 Allgemeine Java-Themen 10
L Java6 update N bekommt neues Browser-Plugin, bitte testen. Allgemeine Java-Themen 7
H Java6 Scripting Framework. Allgemeine Java-Themen 3
0 Unter Java6 kompilierte Klassen mit JRE1.5 ausführen? Allgemeine Java-Themen 6
T Klassen Override Problem Allgemeine Java-Themen 7
L Eclipse Editieren des Code templates für Override methods Allgemeine Java-Themen 2
G Override String.contains Allgemeine Java-Themen 2
S Override will nicht funktionieren :/ Allgemeine Java-Themen 2
reibi Annotation @Override Allgemeine Java-Themen 6
R Fehler:method does not override a method from its superclass Allgemeine Java-Themen 3

Ähnliche Java Themen

Neue Themen


Oben