Interface Interface / Klasse - wieso Abstract?

[ImpCaligula]

Salve!

Ich habe ein „Problem“ dessen Lösung ich nicht hinbekomme. Vor allem deswegen nicht, weil es bei anderen Interfaces und Klassen bereits funktioniert, nur bei dieser einen Kombination nicht. Aber von vorne.

Ich habe folgendes Interface:

public interface IMeineKlasse extends IInterfaceA<IInterfaceB> {

    public List<IInterfaceB> getMethode(Integer id);

}

Und dann habe ich nachfolgende Klasse:

public class MeineKlasse implements IMeineKlasse {

@Override
public List<IInterfaceB> getMethode(Integer id) {
        return irgendetwas;
    }

}

---
Ihr seht, dass ich einfach ein IMeineKlasse Interface habe und eine MeineKlasse Klassendatei, welche das Interface implementiert. Dann die Methode getMethode mit @Override. Genau so mache ich das bereits mit anderen Interfaces und Klassen - ohne Probleme und ohne für mich erkennbare Unterschiede.

Wenn ich jetzt einen Build mache meldet mir Jenkins:

[ERROR] COMPILATION ERROR :
error: MeineKlasse is not abstract and does not override abstract method getMethode() in IMeineKlasse [ERROR]
error: method does not override or implement a method from a supertype [INFO] 2 errors [INFO]

---
Und nun hänge ich da irgendwie ohne weiter zu kommen. Wäre für Eure Hilfe sehr dankbar...

 

[stg]

Dann liegt der Fehler woanders, aber nicht beim hier geposteten Code-Schnipsel.
Prüfe zuerst einmal, ob du wirklich die aktuellste Version deines Source-Codes zu kompilieren versuchst. Vielleicht ist das ausversehen was durcheinander gekommen?!

 

[ImpCaligula]

Danke schon mal. Auch wenn Deine Antwort keine Lösung ist - ist sie für mich wichtig. Man weiß ja nie 100% ob man den Fehler dick vor Augen einfach übersieht. Aber dann kann ich schon mal ausschließen, dass ich einen Code Fehler an sich habe - sprich Interface, Klasse und Verritte benutze ich richtig... und Klassen müssen nicht unbedingt abstrakt gemacht werden wegen dem Override....

Aber wie gesagt - oftmals denkt man, man weiß die Syntax Regeln und es ist eben nicht so...
Daher schon mal Danke für Dein Feedback!

 

[Dompteur]

"@Override" wird verwendet, wenn du in einer abgeleiteten Klasse eine Methode überschreibst. Da deine Klasse aber von Object abgeleitet ist, macht "@Override" hier keinen Sinn.
Weiters erweitert dein Interface ein anderes. In deiner Implementierungsklasse musst du auch die Methoden dieses Interfaces implementieren.
Sollte dir das nicht helfen, wäre es gut deine Interface-Hierarchie und deine Klasse hier zu posten.

 

[ImpCaligula]

GELÖST

Danke an Eure Hilfe, so wusste ich, dass der Code an sich nicht falsch war. Die „Lösung“ - war ein Build Problem. Nach zig Maven Clean Installs und Re-Builds hat er die Verbindung Interface und Klasse kapiert und es geht ^^

 

[RalleYTN]

"@Override" wird verwendet, wenn du in einer abgeleiteten Klasse eine Methode überschreibst. Da deine Klasse aber von Object abgeleitet ist, macht "@Override" hier keinen Sinn.
Weiters erweitert dein Interface ein anderes. In deiner Implementierungsklasse musst du auch die Methoden dieses Interfaces implementieren.
Sollte dir das nicht helfen, wäre es gut deine Interface-Hierarchie und deine Klasse hier zu posten.

@Override wird verwendet wenn man Methoden überschreibt. Das kann entweder Zwanghaft durch abstrakte Methoden in Superklassen oder dem Implementieren von Methode eines Interfaces sein. Es geht aber auch einfach so. Allerdings nur wenn die Methode in der Superklasse nicht als final deklariert wurde. Das @Override in dem gepostetem Codeschnipsel macht durchaus sinn.

 

[Tom299]

Wieso war das jetzt ein Build-Problem? Es ist, wie Dompteur schon angemerkt hat, so, daß deine Klasse auch die Methoden von IInterfaceA<IInterfaceB> implementieren muß. Das sagt dir aber Eclipse schon direkt beim coden. Es sei denn, du hast das schon stillschweigend nachgezogen. Kann mir aber nicht vorstellen, daß Maven das irgendwann einfach baut, obwohl die Methoden nicht implementiert wurde, dann wäre das ein dicker Bug im Build-System.

 

[ImpCaligula]

Wieso war das jetzt ein Build-Problem? Es ist, wie Dompteur schon angemerkt hat, so, daß deine Klasse auch die Methoden von IInterfaceA<IInterfaceB> implementieren muß

In InterfaceA und InterfaceB waren / sind keine relevanten Methoden für das „Problem-Interface“...

Ich habe den Code nicht (!) verändert. Einfach mehrmals den Build ausprobiert und auf einmal war es ok. Eclipse hat mir übrigens nichts bemängelt! Seit begin nicht. Nur Jenkins meldete andauernd die Fehlermeldung... Eclipse nicht...

 

[Tom299]

Also bei mir meckert Eclipse:

interface ITestA {
    public int getA();
}

interface ITestBA extends ITestA {
    public int getB();
}

class Test implements ITestBA {
   
    public Test() {
       
    }
   
    @Override
    public int getB() {
        return 2;
    }
}

 

[ImpCaligula]

In InterfaceA und InterfaceB waren / sind keine relevanten Methoden für das „Problem-Interface“...

Ähm ich zitiere mich nochmals... es sind (noch) keine Methoden in den anderen Interfaces
Wenn bei Dir in ITestA keine Methode ist, meckert Eclipse?

 

[Tom299]

In InterfaceA und InterfaceB waren / sind keine relevanten Methoden für das „Problem-Interface“...

Keine relevanten Methoden klang für mich aber nicht so, als wären KEINE Methoden drin. Sondern eher so, daß du die unrelevanten Methoden nicht brauchst, was natürlich nicht geht.
Wenn keine Methoden drin sind, gehts natürlich

 

[ImpCaligula]

Sorry... mein (Kommunikations-) Fehler

Nein. Also keine drin. Und wie gesagt... Eclipse meldete mir nichts. Habe schon an meinen einfachen Java Kenntnissen gezweifelt. Kann ja auch sein, dass man beim Code etwas übersieht. Eclipse nichts - Jenkins meckert. Nach mehreren Build dann auf einmal Jenkins grün... wer das versteht...

 

[Tom299]

Ja das ist eigenartig ... und wenn du bei jeder Änderung am Code dann wieder zig Durchläufe brauchst, um erfolgreich zu bauen, dann viel Spaß

 

[ImpCaligula]

Zum Glück nicht.. denn inzwischen habe ich nun wirklich die Interfaces und Klassen erweitert um weitere Methoden... aber bisher gehts immer beim ersten Build durch. Na ja...

Aber so unlogische Fehler braucht niemand.
Hat mich 1/2 Tag aufgehalten...