Помогите Рефлексия и с чем ее едят.

Ну начнем с того, что мультиверсия - это не ПротоколЛиб. Многие пакеты банально не нужно обрабатывать (изменять на лету).
Ну а если речь всё-таки о либе, то тут всё очевидно: постоянное выделение и высвобождение памяти из-за врапперов пакетов - это явно не улучшает ситуацию. С либой 800 человек, а без него, допустим 900. Ну либо сервер не падает.
По поводу модов не знаю, ни разу дела с такими серверами не имел.

 

В том то и дело, что одинаково держит онлайн. А что еще нужно то? А мультиверсия и делается на протоколе, лалка.
Там быстрее отвалится тикание игроков, чем какой нить протоколлиб.
А вообще лучше спросить у шевчика. Он точно знает, сколько жрет протоколлиб.

Яб сказал, но конкуренция все лела. А то узнают что тот мод может робить без багов на котле .

 

ProtocolSupport не требует ProtocolLib ну вообще никак, это 2 отдельные библиотеки.
ProtocolLib не жрёт почти ничего если его не использовать, это просто +2 элемента в пайплайне тогда.
Если использовать, то оверхед всё равно копеечный ибо все враппер классы нагенерены через cglib. И все методы PacketContainer тоже в общем-то внутри генерятся cglibом для каждого типа пакета.
Для рефлексолюбов, только MethodHandle::invokeExact может иметь скорость выполнения близкой к выполнению обычного байткода, ибо транслируется в соответствующую интсрукцию если повезёт, любая отсальная рефлективная фигня исполняется иногда и в 100 раз медленней. Так что рефлексией нужно пользоваться с умом.

 

Не знаком с технологией cglib, но знающие люди утверждают, что использование PL не очень приветствуется на крупных серверах по тем причинам, что я озвучил выше.
Тут вопрос в том, стоит ли ставить PL лишь ради отправки пакетов.
Что касается рефлексии, то тут не очень понятно, из-за чего падает скорость выполнения (по сравнению с обычным кодом). Допустим, использование конструктора и в том, и в другом случае вызывает цепь конкретных действий: выделение памяти, запись данных объекта, создание ссылки на него.
Скажу честно, абсолютно чистых тестов я не проводил, но в рамках собственных задач рефлексия показывала занятные результаты: например, получение данных из приватного поля вместо использования геттера (который, в свою очередь, производил какие-то ненужные действия).

 

Рефлексия очень медленная. Я уже и сам испытал разницу в скорости в своем плагине. Почему решил отказаться он нее. Ну там где скорость выполнения не играет роль, то вполне можно. Ну или одноразовая рефлексия, тоже не играет роли.
P.s для тестов можешь получить к примеру nbt с итемстака напрямую и рефлексией.

 

Тык

 

У меня руки не из жопы, я клиентский сокет полностью на рефлексии писал с конструкторами и т.д - все работает. В любом случае добавить вывод ошибки - дело 1 минуты.

 

Это не повод игнорировать исключения. Вроде опытный кодер, а до сих пор не знаешь, что программирование - это магия

 

Ты не поверишь, но я просрал 2 часа из-за:
1) getConfig().getConfigurationSection("blabla").getKeys(true)
Не знал на что влияет аргумент функции getKeys(boolean) и раньше он мне не мешал, все работало. В этот раз не свезло. Надо было просто поменять на false.
2) Забыл, что в функции split(String) есть очень проблемы с символами.
Сделал split("|"), после долгих мук заметил и вспомнил, что надо split("[|]")...

Вот тебе и из-за мелочей дичь выходит. А еще из-за того, что пишешь все подряд без тестов.

 

Именно поэтому не надо игнорировать исключения. Банального e.printStackTrace() хватит чтобы не улететь в космос в случае чего. Да и человек выше прав: доки - наше всё. Но одному другому не мешает

 

Напоминает поиски двери в стене с помощью ударов головы

 

Как-то очень слабо, я думал будет интереснее. Это ж от руки за 5 минут пишется.
А где же всякое получение методов по аргументам, манипуляции с финальными объектами, добавление энамов в конце концов?

 

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

 

@Qmaks
Вообще лучше было бы передавать эти исключения выше. Тогда не потребовалось бы возвращать null, с которым только лишние проверки появляются.

 

Да, верно.

Добавил изменение полей (Даже если они финальные).