Will we use Reflection for SpongePowered?

I’ve seen many examples many times of code that will use a form of reflection to actually get around NMS from Bukkit.

If you’re unsure of what reflection will do, it will access classes without a direct class reference, if that makes sense.

Example of what I mean:

public class Player {

	private Class<?> reflectedPlayer;

	public Player(World world) {
		try {
			reflectedPlayer = Class.forName("net.minecraft.server." + VERSION_NUMBER + ".EntityPlayer");
			Constructor<?> reflectedPlayerConstructor = reflectedPlayer.getConstructor(Class.forName("World"));
			reflectedPlayer = reflectedPlayerConstructor.newInstance(world.NMSWorldInstance());
		} catch (Exception e) {
			// do something here?

Or something similar. I never did get into reflection myself, but if this isn’t already planned, would it be a good option?

Although I find this option great, I have read that reflection isn’t the best way to do this because the java compiler doesn’t get to do something special to it. As well, I think it said it’s not that safe, if not implemented correctly.


Sponge won’t be accessing any NMS code, due to not wanting the same fate as Bukkit’s.

I was thinking that they were only going to not distribute a decompiled version, so now that makes it interesting. If they don’t access the NMS code, how will they actually call specific code through Minecraft?

Forge (uses MCP)

1 Like

NMS operations will still be accessible via Forge though:

That is incorrect. Sponge will access and modify NMS code(and that will be both done using reflection as well as asm). However, the implementation will not include NMS code itself. Forge and FML also do not include the mc code,but require the MC server to be present when starting so that it can patch the code at runtime. This means that it is not needed to have the MC code included in the implementation.

I think using reflection, isn’t a goal sponge wants to accomplish. Its more avoid the use of it.

1 Like

Reflection can be used fine in the implementation. It just depends on where and when it is used. For simple one of setters or getters it doesn’t really matter if reflection is used or not. For stuff that would need to be called every tick then reflection would be a bad idea. And for those situations Access Transformers(ATs) can be used. ATs uses asm to make private field/methods public(or non-final).

Off course it could be used their. (although I wouldn’t do it, as it hurts the readability). What I mean is that it isn’t a goal of sponge to encourage the use of reflection in plugins.
If they need more access they just could make a forge (server) mod.

Well yes. I wasn’t talking about plugins. For plugins all asm and reflection would be discouraged because that locks it to an implementation.

I recall reading about them doing it through Forge, but I forgot, so that was my mistake. I understand that Reflection is messy, but I suggested it because of not accessing packages directly, and hoping for more compatibility among versions. Some of the other information posted helps to kind of get a feel into how things will work.

Have a nice day. :smile:

The need to use reflection is generally a symptom of a problem (e.g. lack of API functionality), not a goal in itself. Hopefully this will be far less necessary with the Sponge API than it was with the Bukkit API.

While we should have access to core MC code via Forge/MCP, this should also be used with caution; one of the goals of the Sponge project is to have multiple implementations (Forge, Glowstone, MC API). Calling methods via MCP will ensure your plugin only works on the Forge implementation.

NMS still remains one of the dumbest thing added to bukkit.

1 Like

What does this even mean? NMS wasn’t “added to” Bukkit in any way I can possibly interpret that phrase.

1 Like

My guess would be the fact that it was available to plugin authors.

The real fact is, that it wasn’t available if they would use the API jar. But I also sinned on that :trollface:.

There is no real reason to use reflection.