Discussion in 'Resources' started by bigteddy98, Apr 26, 2014.
This resource is no longer availabe.
bigteddy98 Hey, I don't know if you are interesed in it, but anyway. There is a way in Java to compile a class on runtime and use it afterwards.
So it might be possible to compile the needed class directly onEnable(). Of course this is even more complicate then reflection, but you might be able to create your wrapper for packets dynamically.
Might grant some more possibilities then creating a shitload of classes for every java-version.. or maybe just hold code for a range of versions and just recompile the imports.
That's pretty awesome, I will check it out.
But you have to do some more research.. I have no idea how this behave on reloads, if you have to dispose something and which negative come with this.. if you want to do this together with me contact me on skype or pm
Now there are three threads. I hope I inspired you
bigteddy98 I hope this is OK to post, but for those who want to work with Maven, mbaxter wrote a similar tutorial at https://forums.bukkit.org/threads/support-multiple-minecraft-versions-with-abstraction-maven.115810/
Why wasn't I able to find that before I started writing this... xD Well, now you can choose between two ;p
At my opinion, many will find your solution way easier, I really have struggled with the Maven modules, but finally got it working.
Thanks, I already had a way to do this, but this way it's so much cleaner. My eclipse package explore is filled with all the compatibility packages now, but it's better this way
Dynamic class generation/editing can be very cool but is it really worth it to do this? If you have a huge plugin then it may be helpfull but otherwise I can't think of any reason why you would take that direction. It is often not that stable and very dangerous when you have no idea what you're doing. Learning bytecode and the internals of the JVM can be very hard + reviewing plugins that use dynamic class generation isn't that easy too. It is often safer and easier to use abstraction like bigteddy showed in his tutorial.
CaptainBern Hehe, I know. We talked about that. I think that reflection is more useful for that, but it won't damage you if you learn it.
i'm a little scared to try multiple modules... but the idea of supporting multiple versions for backwards compatibility is too tantalizing.
Anyways, I made plenty of copies (as well as another git branch) in case things go wrong. Like you point out tho, it's only a matter of time
Technically step 3 is reflection. However, except for creating huge numbers of classes, I like the idea of using an abstraction interface and multiple implementation classes, but I really only see the need when dealing with obfuscated NMS (as unobfuscated names are unlikely to change).
sometimes that better way than reflections
EG: you can't extend class from NMS using reflections
So then you have only 2 way - write it without reflections or use super complicated libs to generate it in runtime
But I also think than every dev can find that way without tutorials when he need it
I have other system in my plugin... I just have abstract class "NMSModule" with abstract onEnable and onDisable method, and some other methods. (plugin is only using some packet listeners, so I don't need using any other interfaces)
ASM bytecode engineering is usually better than reflection in the long run. The first run will be slow since you need to generate the bytes to the classfile and compile it, but you should cache it (I like the cache implementation you've made on Yggdrasil, I like it ), and it WILL be faster than reflection and more dynamic than this in the long run.
However, the JIT won't be able to optimize it like reflection. Doing something like it here, still trying to get it to work https://github.com/AgentTroll/Bukki...ava/com/gmail/woodyc40/commons/reflection/asm
xTrollxDudex Almost any bytecode engeneering library is faster than reflection. The ASM-library is just optimized to do as less as possible until the developer asks for a specific action to be done.
If I were you I'd rather use another bytecode lib than Sun's. Sun's bytecode library is specifically designed to support the instrumentation and proxy API. In JBEL I actually don't care about the performance, once you read a class, it will parse every single value present in the class, which will also allow you to edit specifc values easier. At the moment it's not really able to generate a proper class on runtime, but well it's a WIP .
My main issue with bytecode manipulation and bukkit is that I do not see why the average plugin needs bytecode. Sure it's all fantastic (and uber-sexy) but I don't think it's worth it except if your name is Comphenix. To be honest, it's a pain to review plugins that make use of such code. At the moment there are 2 plugins I know of that make use of this and god bless their authors for making it so clear, bytecode isn't hard, but it can take quite a while to scan every instruction for malicious code.
Also, most people on here barely know how java actually works (on a bytecode level) so I think it's very wrong to promote these kinds of things. Bytecode isn't something you (can and should) learn by a tutorial.
If you want create own mobs without NMS imports ?
Or override any class from bukkit/MC - to change authorization process, to change mobs, to change chunk loading. So many ideas but no time :<
You can't extend class via reflections :<
Smerfa abstraction is a better alternative here.
Separate names with a comma.