[Решено] Mojang AuthLib и Java Reflection...

Здравствуйте, прошу небольшой совет.

Я пишу небольшой класс-враппер для minecraft.jar.
В нём я конструирую новый URLClassLoader со списком URL до всех стандартных майновских библиотек и до самого себя (minecraft.jar); указываю parent class loader = null.
Затем, используя его, загружаю с инициализацией несколько классов из AuthLib и с помощью рефлексии подменяю им private static final URL поля на свои значения. Тут всё происходит удачно.
JD-GUI показывает, что эти поля в свою очередь конструируются через вызовы метода другого класса (хотя по факту он делает new URL(url)), что вроде бы должно на 99% предупредить их inline-овость при компиляции (см. JLS 15.28).
Затем переключаю контекстный класслоадер текущего потока на новый, достаю main класс игры, и запускаю его.

Проблема: игра всё равно пытается достучаться до старых URL.
Что я мог упустить?

 

Заем такое изврщение? Тупо передать майн классу класспатчи и все не?

 

Поля с модификатором final являются константами, их значения не меняются ни при каких обстоятельствах.

В твоем случае все URL инициализируются в момент загрузки класса и последующие операции с Reflection API не смогут изменить значения final-полей

Убери со всех меняемых полей модификатор final и будет тебе счастье. (*но осторожней, объявление констант обычными полями может аукнуться последствиями)

 

Konstantin773, поля эти внутри моджанговской библиотеки, и перекомпилировать я ее не хочу, соответственно и убрать final из кода не могу. Но я снимаю флаг final после загрузки класса класслоадером, класс инициализирован, значит инициализирующее значение не перезапишет мое. После подмены возвращаю и final, и private.

alexandrage, можешь выразиться чуть более подробно, я не очень уловил. Тем временем пойду прогуглю эти словосочетания...[DOUBLEPOST=1397832063,1397794148][/DOUBLEPOST]Вечерний ап.
Ничего нового никто не может предложить? Я в тупике)

 

Если тебе нужен тупо запуск, погляди в сашке.

 

Через некоторое время был найден ответ, но я забыл про него сразу написать.
В клиент был вшит LiteLoader, который сам создавал собственный ClassLoader и, соответственно, подменяемые классы имели новые instance-ы.
Решение оказалось простым, нужно проводить подмену в рамках конечного КлассЛоадера, для чего один из классов реализовал интерфейс ITweaker и был передан как --tweakClass путь.к.классу.

Тема закрыта.