anchor.diff:  in situations where Java might become confused by Groovy's "plumbing" methods.
   
   The feature is incubating. Currently, the presence of the annotation should be
  -treated like a hint to the compiler to produce bytecode not relying on the Groovy runtime
  -if it can but not a guarantee. Users of `@CompileStatic` will know that certain dynamic
  +treated like a _hint_ to the compiler to produce bytecode not relying on the
  +Groovy runtime if it can, but _not a guarantee_.
  +
  +Users of `@CompileStatic` will know that certain dynamic
   features aren't possible when they switch to static Groovy.
  -Even so, while the desire is to produce Java-like code,
  -there are numerous Groovy feature which still work for some scenarios.
  +They might expect that using `@CompileStatic` and `@POJO`
  +might result in even more restrictions.
  +This isn't strictly the case.
  +Adding `@POJO` does result in more Java-like code in certain places,
  +but numerous Groovy features still work.
   
   Consider the following example. First a Groovy `Point` class:
   
  
positive.code: 
  Note that while our `PointList` class has numerous list methods available
  (`size`, `contains`, `forEach`, `stream`, etc.) courtesy of Groovy's `@Delegate` transform,
  these are baked into the class file, not calling into any Groovy library or runtime code.
  
  When run, the following output is produced:
  
  
negative.code: }
  --------------------------------------
  
  We can compile those classes using `groovyc` in the normal way
  and should see the expected _Point.class_ and _PointList.class_ files produced.
  
  We can then compile the following Java code.
  We do not need the Groovy jars available for `javac` or `java`,
  we only need the class files produced from the previous step.
  