Лично, хотя оба из наиболее популярных на данный момент ответов верны, я не думаю, что любой из них решает проблему элегантным, многократно используемым способом, особенно если вам приходится делать это очень часто.
Предположим, у вас есть какой-то старый унаследованный код / зависимость, которую вы никак не можете изменить (чтобы он хотя бы принял List<? extends Object>
, как @ReverendGonzo предложил в своем комментарии . Предположим также, что вам нужнопоговорите с этим унаследованным модулем много.
Я не думаю, что любое приведение / копирование все время будет терпимым в долгосрочной перспективе. Это делает ваш код уязвимым для коварных ошибок и трудно поддающимся отслеживанию или незначительным (илирадикально) неэффективно и трудно читаемо.
Чтобы иметь читаемый и эффективный производственный код, лучше инкапсулировать грязную часть в отдельный модуль, который имеет дело с в противном случае безвредным, но уродливым приведением.
class ProductionCode {
public void doJob() {
List<String> strings = Arrays.asList("pear", "apple", "peach");
StringMagicUtils.dealWithStrings(strings);
}
}
class StringMagicUtils {
@SuppressWarnings("unchecked")
public static void dealWithStrings(List<String> strings) {
ExternalStringMagic.dealWithStringsAsObjects((List) strings);
}
}
// Legacy - cannot edit this wonderful code below ˇˇ
class ExternalStringMagic {
public static void dealWithStringsAsObjects(List<Object> stringsAsObjects) {
// deal with them as they please
}
}