[Tutorial] Get your NMS/OBC working for multiple versions [NO Reflection]

Discussion in 'Resources' started by bigteddy98, Apr 26, 2014.

Thread Status:
Not open for further replies.
  1. Offline


    This resource is no longer availabe.
    SpiritGamerr, TigerHix and Monowii like this.
  2. Offline


    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.
    Read here:
    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.
    TigerHix likes this.
  3. Offline


    That's pretty awesome, I will check it out.
    Slikey likes this.
  4. Offline


    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

    have fun^^
  5. Offline


    Now there are three threads. I hope I inspired you :p
  6. Offline


    mbaxter likes this.
  7. Offline


  8. Offline


    At my opinion, many will find your solution way easier, I really have struggled with the Maven modules, but finally got it working. :p
    Europia79 and bigteddy98 like this.
  9. 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 :p
  10. Offline

    Forge_User_78313302 Retired Staff

    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.
  11. Offline


    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. :)
  12. Offline


    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 [fire]
  13. Offline


    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).
  14. Offline


    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 :p

    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)
  15. Offline


    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 :p https://github.com/AgentTroll/Bukki...ava/com/gmail/woodyc40/commons/reflection/asm
  16. Offline

    Forge_User_78313302 Retired Staff

    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.
    Comphenix and Smerfa like this.
  17. Offline


    If you want create own mobs without NMS imports ? :p
    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 :<
  18. Offline

    Forge_User_78313302 Retired Staff

    Smerfa abstraction is a better alternative here. :p
    Smerfa and xTrollxDudex like this.
Thread Status:
Not open for further replies.

Share This Page