To be honest, this sounds like an implementation problem.
Players are supposed to be a subclass of Human which is a Carrier, meaning the Player class should have the Carrier#getInventroy() method.
It’s likely that this boils down to unimplemented territory.
In the 2.1 api snapshot, it states Player extends Human. If I open the declaration of Human, it states Human extends Carrier. Inside of Carrier I find:
public abstract CarriedInventory<? extends Carrier> getInventory();
This means it has to be something with how I’m getting the Player. I’m going to try to think of different ways of doing this.
Oh I figured out what it is I think. I’m now getting java.lang.AbstractMethodError, instead of the java.lang.NoSuchMethodError. Does this just mean it’s not implemented? I’m not familiar with abstract methods. @FerusGrim
Pretty sure that’s right.
Are there any sponge developers that we could tag and verify this with?
The inventory API is not implemented.
@mumfrey is working on it and we will hopefully see some progress soonTM
Thanks @simon816! Is there anywhere I can follow this development? Or should I just watch the github commits? 
There’s nothing in the repo yet, so just keep refreshing the commit history until there’s a commit “Implemented inventory API” or something 
Perfect thanks! And for the record, if a method is abstract does that usually mean it’s just not implemented yet?
Correct, it means the method is defined for the interface, but the implementation is lacking the method being added. Even though EntityPlayer does implement Player, it doesn’t mean that at the byte code level that it implements all methods of Player. This is why there are AbstractMethodErrors on many api calls.
Makes sense, and to go even deeper, if it’s an interface, does it mean it has at least one unimplemented method/value, but may have implemented ones? An example of this would be how
public abstract interface PlayerBreakBlockEvent
extends HumanBreakBlockEvent, PlayerChangeBlockEvent
{}
is clearly abstract, but does not create an exception and works in plugins I’ve made. Am I correct, or are interfaces different?
Adding the abstract modifier to interfaces is no longer required and therefore is no longer recommended. Same goes with adding public to interface methods.
An interface, if being exposed as a stable public API, should have most to all methods implemented on some level since it is being publicly shared and therefore be working.
Sponge is not at a stable-release yet, it is still under heavy development.
It all depends on the implementation, some interfaces are fully implemented, others are lacking implementation. The only way you can get an AbstractMethodError is when you’re calling a method that is contractually accepted but just not implemented. So, if you just never call a method, well, you’ll have no errors ;).