Я бы не удивился, если бы это была ошибка в вашем компиляторе. Благодаря серьезному использованию обобщений (то, что вы делаете, комбинируя параметризованные методы, ограниченные подстановочные знаки и другие «продвинутые» варианты использования обобщений), я столкнулся с двумя или тремя проблемами в прошлом году в javac (досадно, один и тот же модуль часто отлично скомпилируется в IDE).
В вашем случае я вполне уверен, что это ошибка, поскольку компилятор жалуется на то, что extractor.extractEnum
возвращает Object
, а не RETURN_TYPE
. И независимо от того, какой сумасшедший вывод это делает с вашими аргументами метода enum ... он знает из сигнатуры типа, что Extractor является Extractor<RETURN_TYPE>
, поэтому вы должны всегда иметь возможность скажем return extractor.extractEnum(...);
.
Доказательством тому является то, что даже если вы вызываете метод с аргументом null
(таким образом, полностью устраняя любые возможные осложнения из обобщенных перечислений в аргументе), компилятор все равно будет жаловаться. В частности, теперь говорится, что он думает, что тип возвращаемого значения из Extractor - U<RETURN_TYPE>
, что является явно мусором.
Как правило, решение этих проблем заключается в некоторых явных приведениях. Доволен ли компилятор, если вы приведете вывод extractEnum к RETURN_TYPE? Редактировать : нет, это действительно не так - он жалуется, что U<RETURN_TYPE>
и RETURN_TYPE
необратимы - эээ ...
Если вы используете недавний компилятор 1.6, я советую вам сообщить об этом в Sun, так как это довольно большая проблема с javac. Вот очень короткий тестовый пример, в котором это делается:
public class Test {
interface Sub<O> {
public <I extends Enum<I>> O method(final Class<I> enumType);
}
public static <O> O go(final Sub<O> sub) {
return sub.method(null);
}
}
P.S. Общепринято использовать одну заглавную букву для обозначения параметров общего типа. Я не собираюсь говорить «я прав, вы не правы», но имейте в виду, что я нашел ваш код намного сложнее для чтения и слежения, чем если бы вы использовали вместо этого Extractor. (И, судя по формулировкам Хемаля его ответа, для него тоже самое.)