Тип Литье с универсальными типами в JAVA [дубликат]

На самом деле, это не ошибка дизайна, и это происходит не из-за внутренних компонентов, а из-за производительности. Это происходит просто из-за того, что функции в Python являются первоклассными объектами, а не только частью кода.

Как только вы додумаетесь до этого, тогда это полностью имеет смысл: функция - объект, оцениваемый по его определению; параметры по умолчанию являются «данными-членами», и поэтому их состояние может меняться от одного вызова к другому - точно так же, как и к любому другому объекту.

В любом случае Effbot имеет очень хорошее объяснение причин это поведение в Значения параметров по умолчанию в Python . Я нашел это очень ясным, и я действительно предлагаю прочитать его, чтобы лучше узнать, как работают объекты функций.

205
задан FabienB 28 July 2011 в 19:34
поделиться

9 ответов

Ну, во-первых, вы теряете память при новом вызове создания 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 во время выполнения, потому что генерики не могут заблокировать это в этом случае.

219
ответ дан chelmertz 21 August 2018 в 01:01
поделиться
  • 1
    Это было давно, но я искал ответ на проверку типа Set & lt; CustomClass & gt; перед броском, и вы не можете использовать экземпляр на параметризованном родовом значении. например if (event.getTarget instanceof Set & lt; CustomClass & gt;) Вы можете ввести только тип проверки с помощью? и это не приведет к удалению предупреждения о броске. например if (event.getTarget instanceof Set & lt;? & gt;) – garlicman 14 February 2012 в 17:56

Как указано выше, список не может быть дифференцирован между 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 содержит какие-то объекты. Это проверяет тип каждого объекта в Списке по мере его доступа.

59
ответ дан Amarghosh 21 August 2018 в 01:01
поделиться
  • 1
    ты прав, мой друг. Вместо того, чтобы лить список, просто повторите его и отбросьте каждый элемент, предупреждение не появится, удивительно. – juan Isaza 5 October 2015 в 03:29
  • 2
    Это устранило предупреждение, но все же я не уверен: P – mumair 3 January 2017 в 11:52
  • 3

Ниже кода причины Тип безопасности Предупреждение

Map<String, Object> myInput = (Map<String, Object>) myRequest.get();

Обходной путь

Создайте новый объект карты без указания параметров потому что тип объекта, хранящийся в списке, не проверен.

Шаг 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()); 
    }
0
ответ дан Andy 21 August 2018 в 01:01
поделиться

Предупреждение именно это. Предупреждение. Иногда предупреждения не имеют значения, иногда это не так. Они используются, чтобы привлечь ваше внимание к чему-то, что, по мнению компилятора, может быть проблемой, но может и не быть.

В случае бросков он всегда будет давать предупреждение в этом случае. Если вы абсолютно уверены, что конкретный бросок будет в безопасности, вам следует рассмотреть возможность добавления аннотации, подобной этой (я не уверен в синтаксисе) непосредственно перед строкой:

@SuppressWarnings (value="unchecked")
22
ответ дан David M. Karr 21 August 2018 в 01:01
поделиться
  • 1
    -1: предупреждение никогда не должно приниматься. Или подавите эти предупреждения или исправьте это. Наступит момент, когда вы будете иметь много предупреждений, и вы не увидите соответствующий один раз. – ezdazuzena 16 October 2013 в 10:58
  • 2
    Вы не можете действительно избегать предупреждений о бросании классов при кастинге параметризованных дженериков i.e Map, так что это лучший ответ на исходный вопрос. – muttonUp 8 March 2015 в 12:10

Вы получаете это сообщение, потому что getBean возвращает ссылку Object, и вы переводите ее в правильный тип. Java 1.5 дает вам предупреждение. Это характер использования Java 1.5 или лучше с кодом, который работает так. Spring имеет тип версии

someMap=getApplicationContext().getBean<HashMap<String, String>>("someMap");

в списке задач.

9
ответ дан David Nehme 21 August 2018 в 01:01
поделиться

Еще одно решение, если вы обнаружите, что вы очень сильно набрасываете один и тот же объект, и вы не хотите, чтобы ваш код был помечен с помощью @SupressWarnings("unchecked"), было бы создать метод с аннотацией. Таким образом, вы централизуете актерский состав и, надеюсь, уменьшаете вероятность ошибки.

@SuppressWarnings("unchecked")
public static List<String> getFooStrings(Map<String, List<String>> ctx) {
    return (List<String>) ctx.get("foos");
}
1
ответ дан Jeremy 21 August 2018 в 01:01
поделиться

Проблема заключается в том, что приведение является проверкой времени выполнения - но из-за стирания типа во время выполнения нет никакой разницы между HashMap<String,String> и HashMap<Foo,Bar> для любых других Foo и Bar.

Используйте @SuppressWarnings("unchecked") и держите нос. О, и кампания для реинфицированных дженериков в Java:)

265
ответ дан Jon Skeet 21 August 2018 в 01:01
поделиться
  • 1
    Я возьму Java-редифики для нетипизированного NSMutableWhatever, который ощущается как десятилетний прыжок назад в любой день недели. По крайней мере, Java пытается. – Dan Rosenstark 3 August 2011 в 21:21
  • 2
    В точку. Если вы настаиваете на проверке типа, это может быть сделано только с помощью HashMap & lt;?,? & Gt; и это не приведет к удалению предупреждения, поскольку оно не совпадает с типом проверки общих типов. Это не конец света, но раздражает, что вы пойманы или подавляете предупреждение или живете с ним. – garlicman 14 February 2012 в 18:00
  • 3
    @JonSkeet Что такое reify generic? – SasQ 25 April 2016 в 06:27
  • 4

Если вы действительно хотите избавиться от предупреждений, одна вещь, которую вы можете сделать, это создать класс, который простирается от общего класса.

Например, если вы пытаетесь использовать

private Map<String, String> someMap = new HashMap<String, String>();

Вы можете создать новый класс, такой как

public class StringMap extends HashMap<String, String>()
{
    // Override constructors
}

. Тогда, когда вы используете

someMap = (StringMap) getApplicationContext().getBean("someMap");

Компилятор знает, что (более не общий) типы есть, и предупреждения не будет. Это не всегда может быть идеальным решением, некоторые могут утверждать, что этот вид поражений предназначен для универсальных классов, но вы все еще повторно используете все одинаковые коды из общего класса, вы просто объявляете во время компиляции, какой тип вы хотите использовать.

5
ответ дан Rabbit 21 August 2018 в 01:01
поделиться
0
ответ дан João Neto 31 October 2018 в 19:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: