Currently when a plugin wants to get the location of something it calls getLocation() which returns a new Location object. In some scenarios this can cause enough object creation/destruction churn to be a significant overhead. For this cases we add a method that updates a provided Location object so there is no object creation done. This allows well written code to work on several locations with only a single Location object getting created. Providing a more efficient way to set a location was also looked at but the current solution is the fastest we can provide. You are not required to create a new Location object every time you want to set something's location so, with proper design, you can set locations with only a single Location object being created.
Non-living entities can change blocks, specifically falling blocks. This change is a small source break, but mainly a byte-code break (requires plugins to recompile).
If you use BlockFace in any way, to compensate the directionals being incorrect, you can still have backwards compatibility if you add in the handling in your plugin: boolean legacyBlockFace = BlockFace.NORTH().getModX() == -1; (and then handle it accordingly) If you didn't special case your directions to fix what's being fixed here... Hurray! Your plugin should now work.
Reobtaining a constructor is not a trivial operation, this change makes the Material enum store the respective constructors for each MaterialData. Additionally 'fixed' the material tests to use proper generics.
…eative. Fixes BUKKIT-2949
These methods were never intended to be overwritten, and bukkit relies on their internal functionality. Additionally, the methods were inlined in JavaPlugin, but the finality maintains intention.