Personalmente, si bien las dos respuestas actualmente mejor evaluadas son correctas, no creo que ninguna de ellas resuelva el problema de una manera elegante y reutilizable, especialmente si tiene que hacer esto muy a menudo.
Suponga que tiene un viejo código heredado/dependencia que no se puede cambiar en cualquier forma (por lo que sería al menos aceptar List<? extends Object>
como @ReverendGonzo sugirió in his comment. Supongamos también, que necesita hablar con este módulo legado mucho.
No creo que el fundido/copiado todo el tiempo sea soportable a largo plazo. Hace que su código sea vulnerable a errores insidiosos y difíciles de seguir o ligeramente (o drásticamente) ineficiente y difícil de leer.
Para tener un código de producción eficiente y legible, es mejor encapsular la parte sucia en un módulo separado que se ocupa de lo contrario yeso inofensivo pero feo.
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
}
}
'String' es' Objeto' ¿por qué lo necesitas? – khachik
Es posible que deba pasar la lista a una función que espera una 'Lista
¿Qué está tratando de hacer exactamente? Debido a la borradura de tipo, una lista es una lista