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



## Tarmack (3. Aug 2008)

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


----------



## SlaterB (3. Aug 2008)

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


----------



## Guest (3. Aug 2008)

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?
> ...



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


----------



## Beni (3. Aug 2008)

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 (3. Aug 2008)

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.


----------



## Guest (3. Aug 2008)

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?


----------



## Beni (3. Aug 2008)

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


----------



## Guest (3. Aug 2008)

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?


----------



## SlaterB (3. Aug 2008)

siehe auch
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167262
und darin gelinkt
http://blogs.sun.com/ahe/entry/override


----------



## maki (3. Aug 2008)

Anonymous hat gesagt.:
			
		

> Beni hat gesagt.:
> 
> 
> 
> ...


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.


----------



## Guest (3. Aug 2008)

> 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 (3. Aug 2008)

@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 (3. Aug 2008)

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 (3. Aug 2008)

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  ]


----------



## Guest (4. Aug 2008)

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.
> ...



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.


----------

