Problem mit Generic bei unmodifiableCollection

[SimProtect]

Hallo,

Ich habe momentan ein Problem und hoffe auf Eure Hilfe.

Eine bestimmte Klasse hat folgende Signatur und eine bestimmte problematische Methode, die ich hier mal mit angegeben habe.

public class CollectionClass<T, R extends Collection<T>> extends SomeAbstractClass<R> {

    @Override
    public R get() {
        return Collections.unmodifiableCollection(super.get());
    }

}

Bei diesem Versuch erhalte ich immer den Compilerfehler angezeigt:

Incompatible types. Required R but 'unmodifiableCollection' was inferred to Collection<T>: no instance(s) of type variable(s) T exist so that Collection<T> conforms to R

Kann mir bei diesem Problem jemand auf die Sprünge helfen? Kann ich das in Java gescheit lösen? Wenn ja, wie?

Hinterinformationen:
-> Diese Klasse "MUSS" eine unmodifiableCollection zurückgeben (so ist die Anforderung hierfür)
-> An der API der (für diesen Thread so bezeichneten) SomeAbstractClass kann ich nichts ändern. Über das get() gibt sie selbst ein Objekt vom Typ R zurück
-> Alle weiteren Operationen mit und auf der Collection im Rahmen dieser Klasse funktionieren tadellos. Ich kann lediglich keine Read-Only-Ausgabe der hinterlegten Collection herausgeben.

Für etwas Hilfe bzw. Erläuterung wäre ich sehr dankbar.

 

[httpdigest]

Wozu brauchst du den `R` Typparameter? Wenn du kannst, schreibe es so um:

public class CollectionClass<T> extends SomeAbstractClass<Collection<T>> {
    @Override
    public Collection<T> get() {
        return Collections.unmodifiableCollection(super.get());
    }
}

Erläuterung, warum deine Lösung nicht funktioniert: Das Problem ist, dass das Typargument für den Typparameter `R` immer eine ganz ganz konkrete Collection<T> sein wird, und Collections.unmodifiableCollection() aber natürlich nicht exakt denselben Collectiontyp R zurückliefert, sondern eben "irgendein" Collection-Typ, der nur T als Elementtyp hat. Und das stört den Compiler und da hat er ja auch Recht. Denn der Vertrag deiner Klasse sagt ja: Gegeben eine ganz konkrete Collection-Klasse für R, dann gibt get() auch eine Instanz von genau diesem ganz konkreten Collectiontyp R zurück und nicht _irgendein_ Collectiontyp.

 

[SimProtect]

Danke für Deine Antwort. Das hatte ich mir aus dem Fehlertext bereits herausziehen können. (trotzdem vielen Dank für die Mühe und die nette Antwort. Zumal ich da natürlich auch ungeschickterweise nach gefragt habe )
Die Frage ist eher, ob ich das 'irgendwie' so umsetzen kann.

Als ursprüngliche Variante war die Klasse nur auf T getyped und hatte an SomeAbstractClass dann eben Collection<T> weitergegeben (genau, wie Du beschrieben hattest). Das "Problem" daran war, dass ich weiteren Ableitungen von CollectionClass dann "Unschönigkeiten" aufkommen. Nehmen wir einmal an, wir fügen eine weitere Implementierung konkret für Lists, Sets oder Maps hinzu.
Bei Getter bzw. Zugriffen auf die Felder entsprechender Oberklassen kann ich dann noch casten <- sollte kein Problem darstellen, da "ich ja weiß" (blödes Argument, ich weiß), was für ein Typ ich reingeben.
Ärgerlich wird es dann bei Settern, die natürlich weiterhin Collection<T> annehmen, obwohl ich das natürlich nicht möchte.
Klar, ich könnte jetzt anfangen, dort immer eine RuntimeException (damit nicht jeder Aufruf mit Exception umgehen muss) zu werfen, wenn ein falsches Objekt hereinkommt, aber das wäre nun auch unschön.
Wenn mir die API explizit erlaubt eine Collection reinzugeben, würde ich als aufruf (javadoc mal hin oder her) auch erwarten, dass ich auch genau das kann und mich nicht mehr um solche Feinheiten kümmern zu müssen.

Bei uns befinden sich die entsprechenden Klassen im Framework und sollten solche Unschönheiten den übrigen Entwicklerteams natürlich abnehmen bzw. es sollte möglichst komfortabel sein, das zu benutzen.
Vielleicht habe ich mich hier im Konzept auch schlicht und ergreifend mal wieder völlig verrannt und sehe die offensichtliche Lösung nicht mehr.

Unter anderen Umständen hätte ich diese CollectionClass aus der Veerbungshierarchie von SomeAbstractClass herausgelöst und über einen eigenen Strang verarbeitet, um ein derartiges Problem zu umgehen. Leider haben wir hier (momentan) keinen Zugriff auf die SomeAbstractClass (worüber ich nicht wirklich glücklich bin, da das Ding eigentlich auch Inhousesource ist)

 

[CSHW89]

Damit ich das richtig verstehe, mal nachgefragt: du möchtest also z.B. eine weitere Klasse "ListClass" erstellen, die die Methode "get" besitzt und eine unmodifizierbare Kopie der Liste zurückgeben, die dir die Klasse "SomeAbstractClass" zurückgibt?
Wenn das so ist, kann dies definitiv nicht ohne zusätzlichen Code in der Klasse "ListClass" passieren. Auch wenn dir "SomeAbstractClass.get" eine Liste zurückgibt, die Methode "Collections.unmodifiableCollection" macht dir darauf immer eine Collection. Die zusätzlichen Eigenschaften einer Liste hat diese unmodifizierbare Kopie nicht mehr.

Es gäbe aber zwei Möglichkeiten, die mir einfallen:

public abstract class CollectionClass<T, R extends Collection<T>> extends SomeAbstractClass<R> {
    public R get() {
        return makeUnmodifiable(super.get());
    }
    protected abstract R makeUnmodifiable(R collection);
}

public class ListClass<T> extends CollectionClass<T, List<T>> {
    protected List<T> makeUnmodifiable(List<T> collection) {
        return Collections.unmodifiableList(collection);
    }
}

... oder ...

public abstract class CollectionClass<T, R extends Collection<T>> extends SomeAbstractClass<R> {
    private UnaryOperator<R> converter;
    protected CollectionClass(UnaryOperator<R> converter) {
        this.converter = converter;
    }
    public R get() {
        return converter.apply(super.get());
    }
}

public class ListClass<T> extends CollectionClass<T, List<T>> {
    public ListClass() {
        super(Collections::unmodifiableList);
    }
}

Grüße
Kevin

 

[SimProtect]

Dass die untergeordneten Klassen noch etwas Code benötigen, ist mir klar. Hier war allerdings vorgesehen, die get() erneut zu überschreiben und stattdessen eben eine unmodfiableList o.Ä. zurückzugeben - also letztlich nichts anderes, als das, was Du vorgeschlagen hast - nur mit einer anderen Herangehensweise. (wobei ich die Deine ehrlich gesagt eleganter finde, als meine ursprüngliche )

Die hier so bezeichnete SomeAbstractClass gibt nicht generell eine Collection zurück, sondern bedient alle Arten von Objekten. Collections und co stellen hier lediglich komplexere Implementierungen dar. Somit gibt die get der Oberklasse lediglich vor, dass das ein Element des Typs zurückgegeben wird, auf welches SAC getypt wurde <- also in diesem Falle Collection<T>

Der zusätzliche Code hier wäre auch kein Problem, da die Elemente alle in unserem Framework liegen. Sollte ein Entwickler diese Klasse selbst erweitern wollen, so muss er eben auch damit umgehen, hier noch ein bisschen Hand anzulegen. Die in diesem Thread betrachteten Klassen werden als "fertiges Gesamtpaket" herausgegeben. (anders als andere Elemente des Frameworks, die dann eben erst konkret implementiert werden).

Danke übrigens auch für Deine Codebeispiel: Ich habe dadurch gemerkt, dass ich vergessen hatte, die CollectionClass abstract zu machen. Es wird dringend Zeit für ein paar Tage Urlaub -.-