Помогите Выпадение из мира

Эм. Ток щас заметил аватарку типо моей. Подозрительно как то...

 

ахахахахаах. Бесполезно скрывать)
маил диск... файлы от проекта... XDDD

 

Ну окай. Только приче тут диск? Там все для паблика.

 

Когда то там были файлы не только для паблика.
Ладно, забей. Закрыли тему. Чё прошлое ворошить.

 

А там и не лежит больше ничего на диске.

 

Там какой-то 16-летний негодник твой ник использовал

Spoiler: Пруфы

[DOUBLEPOST=1489308274,1489308032][/DOUBLEPOST]Погоди, зачем ты пытался хакнуть админа того проекта с похожей аватаркой?

Spoiler: Хакаем AuthMe

 

Штирлиц ещё никогда не был так близок к провалу

 

Подолью ещё масла в огонь споров о памяти. У каждого объекта в LVT есть свой номер слота, куда/из которого забирается ссылка одним байткодом aload/astore. А выполнение любого метода скорее всего быдет выполняться байткодом invokevirtual (в зависимости от модификаторов метода). Таким образом данный спор это спор о скорости выполнения 2х байткод операций (в которых разница менее 1нс), и никакого отношения к памяти он не имеет, ибо под LVT память выделена заранее и очень давно.

 

Что и требовалось доказать, но всё равно не поймут.

 

И не поймут, ибо вообще не вникают, как оно работает. Яж говорил, что у них замыкание в голове произошло.

 

А оно ещё и работает по разному, я описал механизм для HotSpot, для остальных виртуальных жаба машин скорость выполнения каждой байткод операции будет отличаться. Только вот всё это капля в море, и незаметно на фоне остальных проблем, типа использования не тех структур данных (ArrayList вместо HashSet для операций где часто применяется .contains, использование LinkedList вместо ArrayDequeue для очереди, некоторые про существование HashMap то не знают, да и вообще плагиноделы зачастую отличаются абсолютным незнанием стандартной библиотеки).

 

Более того, иногда цепляются как раз таки к таким мелочам, не замечая глобальных проблем архитектуры, которые в последствии создают проблемы с той же производительностью, масштабируемостю и дальнейшей поддержкой кода.[DOUBLEPOST=1489322630,1489322482][/DOUBLEPOST]А вообще, кому интересна эта тема и кто знает инглиш, вот книга занимательная: http://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf

 

Больно весёлая тема.
Сейчас ещё скажу, что вместо equalsIgnoreCase лучше сравнивать ссылки на объект при помощи ==

 

Может всё-таки лучше через .equals() всё-таки это не примитив? (Я знаю, что в классе Object внутри .equals используется ==, но что если когда-нибудь этот метод всё-таки переопределят в World?)
Да и нечасто бывают ситуации (по крайней мере у меня), когда экземпляр объекта нужного мира сразу имеется под рукой, чтобы с ним сравнивать, да и бесполезно это ибо в конфигах удобнее писать строки.

 

Так при загрузке конфига можно сразу получить объект мира для дальнейшего сравнивания. Но это бред, ибо не имеет смысла, если только оно не отрабатывает овер900 раз за тик.