anchor.diff:  Note that in normal use cases, that performance gain will hardly be detectable,
   due to massive CPU needs of a realistically complex score calculation...
   
  -One downside of code generation at runtime is that it infers a noticeable bootstrap cost,
  +One downside of code generation at runtime is that it infers a noticeable bootstrap cost (as discussed later),
   especially if the generated code isn't compiled in bulk.
   So I am still hoping that some day MethodHandles will get as fast as direct access,
   just to avoid that bootstrap cost and the dependency pain.
  
positive.code: JavaCompiler        avgt   60  2.726 ± 0.026  ns/op //   5% slower
  LamdbaMetafactory   avgt   60  3.453 ± 0.034  ns/op //  33% slower
  ----
  
negative.code: }
  ----
  
  The full source code is much longer and available in https://github.com/ge0ffrey/ge0ffrey-presentations/tree/master/code/fasterreflection[this GitHub repository].
  For more information on how to use `javax.tools.JavaCompiler`,
  take a look at http://www.informit.com/articles/article.aspx?p=2027052&seqNum=2[page 2 of this article]
  or https://www.ibm.com/developerworks/library/j-jcomp/index.html[this article].
  In Java 8, it requires the `tools.jar` on the classpath, which is there automatically in a JDK installation.
  In Java 9, it requires the module `java.compiler` in the modulepath.
  Also, proper care needs to be taken that it doesn't generate a `classlist.mf` file in the working directory
  and that it uses the correct `ClassLoader`.
  