SpEL documentation refinements

src/docs/asciidoc/core/core-expressions.adoc

@@ -117,8 +117,10 @@ The following example of calling a JavaBean property calls the `String` property
 <1> This line converts the literal to a byte array.
 ====
 
-SpEL also supports nested properties by using standard dot notation (such as
+SpEL also supports nested properties by using the standard dot notation (such as
-`prop1.prop2.prop3`) and the setting of property values. Public fields may also be accessed.
+`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:
 
 ====
@@ -302,18 +304,16 @@ does not provide optimum performance. For occasional expression usage,
 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
+The SpEL compiler is intended to address this need. During evaluation, the compiler
-compiler generates a real Java class that embodies the
+generates a Java class that embodies the expression behavior at runtime and uses that
-expression behavior and uses that to achieve much faster expression
+class to achieve much faster expression evaluation. Due to the lack of typing around
-evaluation. Due to the lack of typing around expressions, the compiler
+expressions, the compiler uses information gathered during the interpreted evaluations
-uses information gathered during the interpreted evaluations of an
+of an expression when performing compilation. For example, it does not know the type
-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
-of a property reference purely from the expression, but, during the first
+evaluation, it finds out what it is. Of course, basing compilation on such derived
-interpreted evaluation, it finds out what it is. Of course, basing the
+information can cause trouble later if the types of the various expression elements
-compilation on this information can cause trouble later if the types of
+change over time. For this reason, compilation is best suited to expressions whose
-the various expression elements change over time. For this reason, compilation
+type information is not going to change on repeated evaluations.
-is best suited to expressions whose type information is not going to change
-on repeated evaluations.
 
 Consider the following basic expression:
 
@@ -382,24 +382,22 @@ following example shows how to do so:
 When you specify the compiler mode, you can also specify a classloader (passing null is allowed).
 Compiled expressions are defined in a child classloader created under any that is supplied.
 It is important to ensure that, if a classloader is specified, it can see all the types involved in
-the expression evaluation process.
+the expression evaluation process. If you do not specify a classloader, a default classloader is used
-If you do not specify a classloader, a default classloader is used (typically the context classloader for
+(typically the context classloader for the thread that is running during expression evaluation).
-the thread that is running during expression evaluation).
 
 The second way to configure the compiler is for use when SpEL is embedded inside some other
-component and it may not be possible to configure it through a configuration object.
+component and it may not be possible to configure it through a configuration object. In these
-In these cases, it is possible to use a system property. You can set the
+cases, it is possible to use a system property. You can set the `spring.expression.compiler.mode`
-`spring.expression.compiler.mode` property to one of the `SpelCompilerMode`
+property to one of the `SpelCompilerMode` enum values (`off`, `immediate`, or `mixed`).
-enum values (`off`, `immediate`, or `mixed`).
 
 
 [[expressions-compiler-limitations]]
 ==== Compiler Limitations
 
-Since Spring Framework 4.1, the basic compilation framework is in place. However, the framework does not
+Since Spring Framework 4.1, the basic compilation framework is in place. However, the framework
-yet support compiling every kind of expression. The initial focus has been on the common expressions that are
+does not yet support compiling every kind of expression. The initial focus has been on the
-likely to be used in performance-critical contexts. The following kinds of expression cannot be compiled
+common expressions that are likely to be used in performance-critical contexts. The following
-at the moment:
+kinds of expression cannot be compiled at the moment:
 
 * Expressions involving assignment
 * Expressions relying on the conversion service
@@ -1272,7 +1270,7 @@ The following example shows how to use the Elvis operator:
 ----
 ====
 
-The following listing shows A more complex example:
+The following listing shows a more complex example:
 
 ====
 [source,java,indent=0]