Their will always be a plugin that will feel the need of using the minecraft code directly instead of the API. Thats why I was thinking. Couldn’t we make a Util called: ReflectionUtil. This Util basically stores the class names so plugins can use reflection on them.

So than they could do this for example.

Object NMSworld = ReflectionUtil.getWorldClass().cast(world);

This would make sure plugins (modules/splugins/…) don’t break that easily every time minecraft would update.

I did not understand what you try?
You want a typesafe access to the nms code?
Sure Forge has this … AccessTransformer?
Not very familiar with Forge atm.

Ps.: You can also use ASM ( to do everything you want xD

All Sponge mods implicitly run in a Forge environment. If you need access to Forge classes, what I’d do is write a Forge mod as normal and also link to the Sponge API jar for any Sponge interaction you need. This is much like people writing plugins linked directly against CraftBukkit and accessing nms, but also interacting with Bukkit API code. The difference here is that Wolveriness isn’t around to ask maven to break your plugins every version.


AccessTransformer is to change private methods to public so forge mods can use them.

I am talking about reflection not ASM. The thing is with the current mappings their is:

  1. No way to import them because they are on the default classpath
  2. No way to find the classes because the dynamically change every update.
  3. Sponge doesn’t wrap the classes so you can’t scan Sponge to find the correct class names.

Example of using reflection on craftbukkit :

Ya you could wrap a mod in to a Sponge Plugin. But that would still break the Plugin/Mod when minecraft updates.

Not necessarily. If you need to call a Forge hook, but you don’t need to interact with obfuscated source, then you’d be fine. That already gives you a huge vocabulary that just can’t go into an abstraction layer.

No it wouldn’t. You can’t guarantee that the members of the class haven’t changed (I’d be willing to bet that they will do), and so plugins will break anyway.

I would really recommend that this was not implemented. As others have said, if you need that sort of access, create it as a Forge mod, or at least reference Forge. Providing an easy way to use reflection is only going to make more plugin authors consider it, more plugins will break on a version change, more server owners will blame Sponge and not the plugin, everyone will get annoyed, and that’s no good for anybody.

If you still insist on using reflection to access the internals of nms, then do so on your own, Sponge shouldn’t help you do that. People would only blame Sponge if something went wrong, even though it isn’t their fault, “because it’s part of the API”. Better not to provide it at all.

For what it’s worth, I didn’t think that was necessarily a bad thing (except for the fact it was a sudden move). A lot of method calls had their names changed when an update was released, and when a major version is released - a lot of methods change/move/disappear. The logic as to why he did that was sound, even if it was a pain in the neck - plugins broke in an obvious way, rather than a weird way - at least you knew what was broken.

Using Forge is a much better solution if you need to access nms.

Ya I just realized that. Its hard to get away from the bukkit way of overseeing things.

Just use the Forge calls to access the nms. If you need direct access that bad write a forge mod that hooks into the sponge API. Sponge is certainly not going to provide this for both copyright reasons and the fact that nms changes with each version and that would have to be kept up with. Just access the nms in the way you want but be aware of the fact that there is a 90% chance that something in the code will change to break your plugin.