We seem to violate principles of good programming by using something that is not a part of published API and by accessing private stuff through reflection. The designers of Unsafe would have thought enough and decided to keep it out of the published API and declaring the function private.
This is setting a bad precedent. The code will not compile where com.sun.Unsafe is not available. There is no guarantee that it will be present in any Java distribution. Neither is there a guarantee that this will be present in Sun's (Oracle's) distribution in later releases.
Traditionally, Java has done not so great job in defining module boundaries. (Package-private is of some use, but not really a great facility). Hadoop community, for example, has taken pains to annotate classes and interfaces to indicate their accessibility outside the module. Java language is trying to fix it in Java 8 using Jigsaw. Once that is in, probably this patch won't work.
I'm not sure if marginal performance improvement in a micro-benchmark is a good enough reason. Do we have evidence that this patch would significantly improve performance in a real application?
Probably, this debate has happened and settled in the Hadoop community or they considered it a Guava's internal matter. Since we decided to use "Unsafe" directly, we should have an opinion. I'm raising it here because even if we accept this patch, I think, we should acknowledge that we are doing it with full knowledge of its consequences.