Best way to ensure version compatibly?

Discussion in 'Spigot Plugin Development' started by gluebaby, May 7, 2017.

  1. I'm gonna be using some NMS for NPC's and I need to make sure that compatibly doesn't break through versions. Reflection is the go to for many people, but I hear that it isn't a very good option. Any ideas on what I should do?
  2. If you don't want to use Reflection for NMS a good alternative would be to use abstraction. A good tutorial on this can be found here. You essentially will create the needed NMS method(s) for each version you want to be compatible with.
    • Agree Agree x 1
  3. In general you got 2 options. Either reflections or interfaces / abstraction.
    Both ways got advantages and disadvantages.

    • Advantages:
      • As long as mojang doesn't rename methods /classes , everything is fine and will still work after updates without doing anything
    • Disadvantages:
      • Hard to maintain
    • Advantages:
      • Easier to understand and maintain
    • Disadvantages:
      • New inplementations has to be added on every single update (when the classpath version gets changed)
    I personally prefer reflections, because i don't want to touch my code on every update.
  4. Reflection will only work for very limited and simple NMS use, personally i prefer having a plugin version for each server version (what almost all plugins that use NMS heavily do), or some abstraction.
  5. Not really. After working a while with it you'll know how to work with it properly, even komplex things.

    All things which can be done without reflections can be implemented by reflections, too. Even more things can be done using reflections.
    #5 Michel_0, May 7, 2017
    Last edited: May 7, 2017
  6. Not remotely correct in this case. Lots of field and method names change every version.
    Give it a try and get back t me when your plugin breaks horrible and causes corruption or crashes, and see how people feel about it.
  7. Choco


    I think what he meant was that it can become unpredictable. Due to obfuscation, method and field names change all the time. It may be one name in one version, but a completely different name in another. This then requires you to have to change the code to reflect the changes either way, so you're going to have to either end up supporting only the most recent version, or just have various classes handling different Minecraft versions. You might as well use abstraction if you're going to be creating multiple classes to use reflection.

    EDIT: Yeaaaa... sniperino'd
  8. Yea, a reflection will throw an exception in this case and break.

    But this:
    Just isn't true. You can do anything with reflections, not only "simple and limited" stuff.

    I prefer to use reflection fallbacks to support different versions when some class / field / method name changes.
  9. Choco


    I do the opposite. I use abstraction in my VeinMiner plugin (PlayerInteractManager#breakBlock() in NMS), but if one of the versions are not supported, it will default to an abstraction that uses reflection. For example, when 1.12 comes along, I may not update instantly, so 1.12 would have been left in the dark until I do, but since it defaults to reflection, it should work fine.
  10. Hmm, well I guess I'll take a look at reflection and see how much of a hassle it would be, and if it's too much work for a limited result then I'll just make 2 versions.