На самом деле, это не ошибка дизайна, и это происходит не из-за внутренних компонентов, а из-за производительности. Это происходит просто из-за того, что функции в Python являются первоклассными объектами, а не только частью кода.
Как только вы додумаетесь до этого, тогда это полностью имеет смысл: функция - объект, оцениваемый по его определению; параметры по умолчанию являются «данными-членами», и поэтому их состояние может меняться от одного вызова к другому - точно так же, как и к любому другому объекту.
В любом случае Effbot имеет очень хорошее объяснение причин это поведение в Значения параметров по умолчанию в Python . Я нашел это очень ясным, и я действительно предлагаю прочитать его, чтобы лучше узнать, как работают объекты функций.
Ну, во-первых, вы теряете память при новом вызове создания HashMap
. Ваша вторая строка полностью игнорирует ссылку на этот созданный хэш, что делает ее доступной сборщику мусора. Итак, не делайте этого, используйте:
private Map<String, String> someMap = (HashMap<String, String>)getApplicationContext().getBean("someMap");
Во-вторых, компилятор жалуется, что вы передали объект в HashMap
, не проверяя, является ли это HashMap
. Но даже если вы должны были сделать:
if(getApplicationContext().getBean("someMap") instanceof HashMap) {
private Map<String, String> someMap = (HashMap<String, String>)getApplicationContext().getBean("someMap");
}
Возможно, вы все равно получите это предупреждение. Проблема в том, что getBean
возвращает Object
, поэтому неизвестно, что это за тип. Преобразование его в HashMap
напрямую не вызовет проблемы со вторым случаем (и, возможно, в первом случае не было бы предупреждения, я не уверен, насколько педантичен компилятор Java с предупреждениями для Java 5). Однако вы преобразовываете его в HashMap<String, String>
.
HashMaps - это действительно карты, которые берут объект в качестве ключа и имеют объект как значение, HashMap<Object, Object>
, если хотите. Таким образом, нет никакой гарантии, что когда вы получите свой bean-компонент, он может быть представлен как HashMap<String, String>
, потому что вы могли бы иметь HashMap<Date, Calendar>
, потому что возвращаемое не общее представление может иметь любые объекты.
Если код компилируется, и вы можете выполнить String value = map.get("thisString");
без каких-либо ошибок, не беспокойтесь об этом предупреждении. Но если карта не полностью содержит строковые ключи для строковых значений, вы получите ClassCastException
во время выполнения, потому что генерики не могут заблокировать это в этом случае.
Как указано выше, список не может быть дифференцирован между List<Object>
и List<String>
или List<Integer>
.
Я решил это сообщение об ошибке для аналогичной проблемы:
List<String> strList = (List<String>) someFunction();
String s = strList.get(0);
со следующим:
List<?> strList = (List<?>) someFunction();
String s = (String) strList.get(0);
Объяснение: Преобразование первого типа подтверждает, что объект является списком, не заботясь о типах, находящихся внутри (поскольку мы не можем проверить внутренние типы на уровне списка). Второе преобразование теперь требуется, потому что компилятор знает, что List содержит какие-то объекты. Это проверяет тип каждого объекта в Списке по мере его доступа.
Ниже кода причины Тип безопасности Предупреждение
Map<String, Object> myInput = (Map<String, Object>) myRequest.get();
Обходной путь
blockquote>Создайте новый объект карты без указания параметров потому что тип объекта, хранящийся в списке, не проверен.
Шаг 1: Создайте новую временную карту
Map<?, ?> tempMap = (Map<?, ?>) myRequest.get();
Шаг 2: Создайте главную карту
Map<String, Object> myInput=new HashMap<>(myInputObj.size());
Шаг 3: Итерируйте временную карту и установите значения в основную карту
for(Map.Entry<?, ?> entry :myInputObj.entrySet()){ myInput.put((String)entry.getKey(),entry.getValue()); }
Предупреждение именно это. Предупреждение. Иногда предупреждения не имеют значения, иногда это не так. Они используются, чтобы привлечь ваше внимание к чему-то, что, по мнению компилятора, может быть проблемой, но может и не быть.
В случае бросков он всегда будет давать предупреждение в этом случае. Если вы абсолютно уверены, что конкретный бросок будет в безопасности, вам следует рассмотреть возможность добавления аннотации, подобной этой (я не уверен в синтаксисе) непосредственно перед строкой:
@SuppressWarnings (value="unchecked")
Вы получаете это сообщение, потому что getBean возвращает ссылку Object, и вы переводите ее в правильный тип. Java 1.5 дает вам предупреждение. Это характер использования Java 1.5 или лучше с кодом, который работает так. Spring имеет тип версии
someMap=getApplicationContext().getBean<HashMap<String, String>>("someMap");
в списке задач.
Еще одно решение, если вы обнаружите, что вы очень сильно набрасываете один и тот же объект, и вы не хотите, чтобы ваш код был помечен с помощью @SupressWarnings("unchecked")
, было бы создать метод с аннотацией. Таким образом, вы централизуете актерский состав и, надеюсь, уменьшаете вероятность ошибки.
@SuppressWarnings("unchecked")
public static List<String> getFooStrings(Map<String, List<String>> ctx) {
return (List<String>) ctx.get("foos");
}
Проблема заключается в том, что приведение является проверкой времени выполнения - но из-за стирания типа во время выполнения нет никакой разницы между HashMap<String,String>
и HashMap<Foo,Bar>
для любых других Foo
и Bar
.
Используйте @SuppressWarnings("unchecked")
и держите нос. О, и кампания для реинфицированных дженериков в Java:)
Если вы действительно хотите избавиться от предупреждений, одна вещь, которую вы можете сделать, это создать класс, который простирается от общего класса.
Например, если вы пытаетесь использовать
private Map<String, String> someMap = new HashMap<String, String>();
Вы можете создать новый класс, такой как
public class StringMap extends HashMap<String, String>()
{
// Override constructors
}
. Тогда, когда вы используете
someMap = (StringMap) getApplicationContext().getBean("someMap");
Компилятор знает, что (более не общий) типы есть, и предупреждения не будет. Это не всегда может быть идеальным решением, некоторые могут утверждать, что этот вид поражений предназначен для универсальных классов, но вы все еще повторно используете все одинаковые коды из общего класса, вы просто объявляете во время компиляции, какой тип вы хотите использовать.