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

Bomber123

Активный участник
Пользователь
Баллы
76
Привет форумчане!
Не давно столкнулся с такой проблемой. Когда я запрашиваю ключи, и открываю кейс с другим игроком то количество ключей у обоих одинаково. Как исправить?
код
 
Последнее редактирование:
Согласен. Хотя чего ожидать от ваниль б****
Да это мои проблемы. Я создам файл в котором буду хранить все ключи игроков. И когда плагин будет включаться я буду все данные из него загружать в Map и тоже самое сделаю с onEnable
 
Да это мои проблемы. Я создам файл в котором буду хранить все ключи игроков. И когда плагин будет включаться я буду все данные из него загружать в Map и тоже самое сделаю с onEnable
Зачем его только с мапами научили работать?
 
И скинул не инкапсулированный код, норм.
Я лишь переделал твой код, убрав возможные NPE.
getOrDefault для кого придумали?
Я знаю об этом методе, но не факт, что ТС использует Java 8. Ну и если ТС сделает что-то не так и запишет в коллекцию null, то "map.getOrDefault(key, 0).intValue()" выбросит NPE. <а если честно, мне было просто лень вспоминать сигнатуру этого метода>
 
Я лишь переделал твой код, убрав возможные 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. А остальные 10% используют Java7. Дня два назад ко мне как раз обращались с ошибкой, возникшей из-за того, что плагин был собран под Java 8, а на сервере стояла Java 7 (владелец опасался обновляться, считая (небезосновательно), что это может что-то сломать).
  2. А кто сказал, что ТС просто скопирует код и будет его использовать? Есть вероятность, что он попробует сделать что-то по-своему. И да, я просто высосал из пальца этот аргумент, так что не стоит его воспринимать всерьёз.
  3. Извиняюсь, перепутал. Код Exception_Prototype.
1.Это их проблемы. Динозавры когда-то уже вымерли, вот и вымрут еще раз.
2.Ничего, будет искать проблему и как раз будет учить джаву на практике, так что еще лучше.
3. Ну ладно😗
 
1.Это их проблемы. Динозавры когда-то уже вымерли, вот и вымрут еще раз.
2.Ничего, будет искать проблему и как раз будет учить джаву на практике, так что еще лучше.
3. Ну ладно😗
+1 на таких пора забить, сам сервак уже под 8 java собирается. Так что овертупо компилить плагин под 7ркой.
 
  1. А остальные 10% используют Java7. Дня два назад ко мне как раз обращались с ошибкой, возникшей из-за того, что плагин был собран под Java 8, а на сервере стояла Java 7 (владелец опасался обновляться, считая (небезосновательно), что это может что-то сломать).
  2. А кто сказал, что ТС просто скопирует код и будет его использовать? Есть вероятность, что он попробует сделать что-то по-своему. И да, я просто высосал из пальца этот аргумент, так что не стоит его воспринимать всерьёз.
  3. Извиняюсь, перепутал. Код Exception_Prototype.
што ты несешь?
про boxing и unboxing в джаве слыхал? JVM сама все сделает если ты кастить к Integer не будешь
 
што ты несешь?
про 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. Пусть код будет менее красивым, зато он не крашнется в неподходящий момент.
 
Правильно, скастит, но если заглянуть в полученный байткод (или просто применить декомпилятор), то сразу будет видна небольшая проблема.
  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, так как интегер в методе.
 
Это физически не возможно, если есть жесткие методы добавить и удалить, где не принимается значение null, так как интегер в методе.
  1. Я, когда писал то сообщение, провёл небольшой тест. NPE вылетает.
  2. HashMap позволяет использовать null в качестве ключей и значений, так что всё возможно.
Java:
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);
 
  1. Я, когда писал то сообщение, провёл небольшой тест. NPE вылетает.
  2. HashMap позволяет использовать null в качестве ключей и значений, так что всё возможно.
Java:
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
    }
 
Ну давай отправь сюда 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 легко отправляется.
 
  1. Сюда действительно нельзя отправить null.
  2. В Map нет метода с такой сигнатурой. Есть "public V put(K key, V value)", который превращается в "public String put(String key, Integer value)" и в который null легко отправляется.
Ты опять начинаешь х*ню стрелять? Я ж уже говорил с тобой об этом...
В Map действительно нет такого метода, но что мешает сделать свой, был*дский, защищённый метод? Нормальные люди не дают полный доступ ко всему классу. Это и называется инкапсуляция-_-
Ты щас гонишь дичь примерно как про java 7.
 
Последнее редактирование:
Не понимаю причину такого негатива по отношению ко мне. Я лишь ответил @xDark насчёт боксинга и @alexandrage насчёт невозможности ситуации, которую я описал. Оба ответа вполне корректны, всё расписано по пунктам. Не спорю, возможно сделать безопасный метод, но ведь обсуждалось совсем не это.
 
Не понимаю причину такого негатива по отношению ко мне. Я лишь ответил @xDark насчёт боксинга и @alexandrage насчёт невозможности ситуации, которую я описал. Оба ответа вполне корректны, всё расписано по пунктам. Не спорю, возможно сделать безопасный метод, но ведь обсуждалось совсем не это.
Обсуждалось как раз это. Нормальный человек думает сразу про решение, а не про какие-то проблемы.
Да и я тебе уже сто раз говорил, что все бы сделали инкапсулированный класс и все. Другого и быть не может.
Вообщем просто больше не неси такую чепуху и я агрится не буду.
 
  1. А остальные 10% используют Java7. Дня два назад ко мне как раз обращались с ошибкой, возникшей из-за того, что плагин был собран под Java 8, а на сервере стояла Java 7 (владелец опасался обновляться, считая (небезосновательно), что это может что-то сломать).
  2. А кто сказал, что ТС просто скопирует код и будет его использовать? Есть вероятность, что он попробует сделать что-то по-своему. И да, я просто высосал из пальца этот аргумент, так что не стоит его воспринимать всерьёз.
  3. Извиняюсь, перепутал. Код Exception_Prototype.
вот пусть и эти динозавры мучаются.
ничего не сломает обновление до Java 8.
 
Назад
Верх