2012-03-29 3 views
0

Ich habe in letzter Zeit auf Generics zu lesen, und ich kam in dieser Methode:Java - Generics Methode

protected <V> RunnableScheduledFuture<V> decorateTask(Callable<V> callable, RunnableScheduledFuture<V> task) { 
     return new ExceptionHandlingFutureTask<V>(callable, task); 
    } 

Sehen Sie, ich verstehe, warum ein <V> nach protected gibt. Was ich nicht verstehe ist warum es wieder eine <V> nach RunnableScheduledFuture gibt. Ich habe diese spezielle <V> aus der Methode genommen, kompiliert und es gab keinen Fehler. Warum also hat der Autor sich entschieden, es überhaupt zu veröffentlichen?

Antwort

2

Im Allgemeinen können Sie immer Generika entfernen „ohne Fehler“, weil sie in Java über Löschung implementiert sind, so dass die tatsächliche kompilierten Code einfach bezieht sich sowieso auf die rohen Klassen. (Das heißt, Sie müssten einige Umwandlungen einfügen, um den Compiler glücklich zu machen).

Im Lichte des letzteren Fall durch die generische Parameter aus der Zukunft zu entfernen, haben Sie es aus „eine Zukunft, die eine V zurückkehren wird“ verwandelte sich in „eine Zukunft, die etwas zurückkehren wird“. Ohne den generischen Parameter müssen die Benutzer das Ergebnis in den gewünschten Typ umwandeln, und der Compiler kann die Richtigkeit für sie nicht überprüfen.

Es ist genauso wie in der Lage, eine rohe ArrayList anstelle von ArrayList<Integer> zu verwenden; beide "funktionieren", aber letzteres ist sauberer, leichter zu verstehen, vom Compiler typgeprüft und erfordert kein manuelles Casting.

+0

Aaaaaaah, ich sehe! Danke vielmals. Macht jetzt viel Sinn :) –

1

Da Sie angeben, dass Sie eine RunnableScheduledFuture<V> zurückgeben, in der V ist der gleiche Typ der Callable Sie in Ihre Eingabe.

Wenn Sie <V> entfernen, werden Sie keinen Fehler, wenn man das Verfahren auf diese Weise rufen

RunnableScheduledFuture<String> rsf = decorateTask(Callable<Integer> callable, RunnableScheduledFuture<Integer> task); 

Aber, wenn Sie die <V> nicht entfernen, dies wird Ihnen einen Compiler-Fehler.

0

Weil er gegossene Warnung will vermeiden, wenn

ExceptionHandlingFutureTask<V> var = decorateTask(...); 
0

Da RunnableScheduledFuture einen parametrisierten Typ erfordert. Obwohl Sie parametrisierten Typ aus Ihrem Code entfernen können (und damit zu einem Raw-Typ werden), wird die Klassendefinition parametrisiert.

Wenn Sie den parametrisierten Typ entfernen, müssen Sie später auf den entsprechenden Typ tippen.