1. To preserve backward compatibility, I chose not to rename Trash to something like TrashPolicyDefault or something. If Trash uses/contains TrashPolicy then it doesn't make sense to have an implementation in it. I think it's best to separate implementation of a Trash policy from what the policy actually is. This is similar to how BlockPacementPolicy has been set up.
2. ReflectionUtils calls the no parameter constructor by default. Therefore we can only really "initialize" the instance after it been returned by ReflectionUtils.newInstance(...).
3. Trash was an instance of Configured, so I pushed that up to TrashPolicy. Another reason why this is useful is that ReflectionUtils does an internal check to see if the Class is an instanceof Configured and calls setConf(...). I don't think it's strictly needed though.
4. checkpoint(), expunge() and getEmptier() were part of the public interface exposed by Trash and since the interface was marked stable, renaming/removing these methods doesn't seem favorable right now. I also think eventually we should remove them from TrashPolicy because it doesn't make sense to expect every Trash policy to have a checkpoint mechanism.
5. If there's a startEmptier() method in Trash, we either fix it to run in a separate thread or in the same thread. By exposing a Runnable, we push this decision to the client which I think might be better.
I will fix the javadocs/indentation issues.