Помогите Как хранить ключи от кейсов игроков в Map

Да это мои проблемы. Я создам файл в котором буду хранить все ключи игроков. И когда плагин будет включаться я буду все данные из него загружать в Map и тоже самое сделаю с onEnable

 

Даже на лечение кидать бесполезно...

 

Зачем его только с мапами научили работать?

 

Не будет, в java 8 синтаксис позволяет делать как я показал.

 

Я лишь переделал твой код, убрав возможные NPE.

Я знаю об этом методе, но не факт, что ТС использует Java 8. Ну и если ТС сделает что-то не так и запишет в коллекцию null, то "map.getOrDefault(key, 0).intValue()" выбросит NPE. <а если честно, мне было просто лень вспоминать сигнатуру этого метода>

 

В данный момент 90% серверов используют Java 8 и все новые плагины сделаны именно на ней. Потому не нужно оправдываться, т.к не использовать Java 8 глупо
По-поводу NPE: Как он, бл*ять, выскочит, если в моём примере можно добавить только через статический метод. Да и то, только примитивный тип данных-_-
Переделал мой код? Еще до того как я его выложил что-ли? Или же это не мне вовсе было?

 

1. А остальные 10% используют Java7. Дня два назад ко мне как раз обращались с ошибкой, возникшей из-за того, что плагин был собран под Java 8, а на сервере стояла Java 7 (владелец опасался обновляться, считая (небезосновательно), что это может что-то сломать).
2. А кто сказал, что ТС просто скопирует код и будет его использовать? Есть вероятность, что он попробует сделать что-то по-своему. И да, я просто высосал из пальца этот аргумент, так что не стоит его воспринимать всерьёз.
3. Извиняюсь, перепутал. Код Exception_Prototype.

 

1.Это их проблемы. Динозавры когда-то уже вымерли, вот и вымрут еще раз.
2.Ничего, будет искать проблему и как раз будет учить джаву на практике, так что еще лучше.
3. Ну ладно

 

+1 на таких пора забить, сам сервак уже под 8 java собирается. Так что овертупо компилить плагин под 7ркой.

 

што ты несешь?
про boxing и unboxing в джаве слыхал? JVM сама все сделает если ты кастить к Integer не будешь

 

Правильно, скастит, но если заглянуть в полученный байткод (или просто применить декомпилятор), то сразу будет видна небольшая проблема.

1. Кладём в HashMap null.
2. Используем "int i = map.getOrDefault(key, 0)".
3. Компилятор это превращает в "int i = map.getOrDefault(key, 0).intValue()".
4. getOrDefault возвращает null, так как именно такое значение лежит в Map (если бы не было ничего, то он вернул бы Integer.valueOf(0), но см. 1 пункт).
5. "int i = ((Integer) null).intValue()" - получаем NullPointerException.

Если во 2 пункте взять "int i = map.get(key)", то результат будет тот же - NPE (и 1 пункт уже не обязателен).
Я с таким неоднократно сталкивался в различных модах и плагинах, так что в подобных ситуациях предпочитаю всё проконтролировать, а не довериться компилятору и JVM. Пусть код будет менее красивым, зато он не крашнется в неподходящий момент.

 

Это физически не возможно, если есть жесткие методы добавить и удалить, где не принимается значение null, так как интегер в методе.

 

1. Я, когда писал то сообщение, провёл небольшой тест. NPE вылетает.
2. HashMap позволяет использовать null в качестве ключей и значений, так что всё возможно.

Код:

Map<String, Integer> map = new HashMap<>();
map.put("test", null);
int i = map.get("test");
int j = map.getOrDefault("test", 0);
System.out.println(i + j);

 

Ну давай отправь сюда null в интовую.

Код:

    void put(String str, int i) {
        //TODO
    }

 

1. Сюда действительно нельзя отправить null.
2. В Map нет метода с такой сигнатурой. Есть "public V put(K key, V value)", который превращается в "public String put(String key, Integer value)" и в который null легко отправляется.

 

Ты опять начинаешь х*ню стрелять? Я ж уже говорил с тобой об этом...
В Map действительно нет такого метода, но что мешает сделать свой, был*дский, защищённый метод? Нормальные люди не дают полный доступ ко всему классу. Это и называется инкапсуляция-_-
Ты щас гонишь дичь примерно как про java 7.

 

Забей, тут все потеряно уже

 

Не понимаю причину такого негатива по отношению ко мне. Я лишь ответил @xDark насчёт боксинга и @alexandrage насчёт невозможности ситуации, которую я описал. Оба ответа вполне корректны, всё расписано по пунктам. Не спорю, возможно сделать безопасный метод, но ведь обсуждалось совсем не это.

 

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

 

вот пусть и эти динозавры мучаются.
ничего не сломает обновление до Java 8.