anchor.diff:  ----
   ====
   
  -The following listing shows A more complex example:
  +The following listing shows a more complex example:
   
   ====
   [source,java,indent=0]
  
positive.code: this is fine, but, when used by other components such as Spring Integration,
  performance can be very important, and there is no real need for the dynamism.
  
  The SpEL compiler is intended to address this need. During evaluation, the
  compiler generates a real Java class that embodies the
  expression behavior and uses that to achieve much faster expression
  evaluation. Due to the lack of typing around expressions, the compiler
  uses information gathered during the interpreted evaluations of an
  expression when performing compilation. For example, it does not know the type
  of a property reference purely from the expression, but, during the first
  interpreted evaluation, it finds out what it is. Of course, basing the
  compilation on this information can cause trouble later if the types of
  the various expression elements change over time. For this reason, compilation
  is best suited to expressions whose type information is not going to change
  on repeated evaluations.
  
  Consider the following basic expression:
  
  
negative.code: <1> This line converts the literal to a byte array.
  ====
  
  SpEL also supports nested properties by using the standard dot notation (such as
  `prop1.prop2.prop3`) and also the corresponding setting of property values.
  Public fields may also be accessed.
  
  The following example shows how to use dot notation to get the length of a literal:
  
  ====
  