Prior to this change SpEL did not have an syntactic
construct enabling easy access to a FactoryBean. With this
change it is now possible to use &foo in an expression when
the factory bean should be returned.
Issue: SPR-9511
Before this change the compilation of a method reference or property/field
access was not properly cleaning up the stack if compilation meant
calling a static method or accessing a static field. In these cases there
is no need for a target object on the stack and it should be removed if
present. For a simple expression it is harmless since the end result of
the expression is the thing on the top of the stack, but for nested
expressions if the inner expression suffered this issue, the outer
expression can find itself operating on the wrong element.
The particular issue covered the case of a static field access but this
fix (and associated tests) cover static method, property and field access.
Issue: SPR-13781
When the plus operator is used between strings in a SpEL
expression and that expression is compiled, it is
important to include a cast if computation of any of
the operands isn't obviously leaving strings on the
stack. Likewise if the stack contents are known to
be strings, a cast should not be included.
Issue: SPR-12426
Before this commit the object that #this would refer to in
nested expressions within projection/selection clauses was always
the root context object. This was incorrect as it should be the
element being projected/selected over. This commit introduces
a scope root context object which is set upon entering a new
scope (like when entering a projection or selection). Any
object. With this change this kind of expression now behaves:
where #this is the element of list1. Unqualified references
are also resolved against this scope root context object.
Issues: SPR-10417, SPR-12035, SPR-13055
This change provides support for map[NEW], map[new], map[T]
and map[t]. Prior to this change the 'new' and 't' had to
be quoted because they were keywords in SpEL for a constructor
reference and type reference respectively.
Issue: SPR-11783
Prior to this change the SpEL compiler would not compile mathematical
expressions where the operands were of differing types (e.g. int
and double). This required the expression writer to do the conversion
in the expression text. For example:
T(Integer).valueOf(someInt).doubleValue()/35d
With this commit the restriction is lifted and it is more like Java
so that you can simply do someInt/35d. The mathematical operators
affected are divide/plus/minus/multiply and modulus. This change
involved removing some guards so that the exitTypeDescriptor (the
trigger for whether compilation is allowed) is set more frequently
and enhancing bytecode generation to perform more sophisticated
conversion/coercion automatically.
Issue: SPR-12789
Without this change when the operands to an == are a mix of a
reference type and a primitive, the failure to box the primitive
would result in a verifyerror when the compiled code is loaded.
Issue: SPR-12557
Without this change the plus operator would fail to
include a CHECKCAST in generated bytecode when it
was compiled in cases where one of the operands
has a runtime type of String but a statically
declared type that was not String (i.e. Object).
Issue: SPR-12426
Before this change isWritable() could return true
for a badly formed expression. That is because the
decision about whether something is writable was made
based on the node type rather than whether the node
represented something that could actually be resolved
to be a real thing. This change ensures a resolution
check is done and isWritable() should only return
true if a subsequent setValue() will succeed.
Issue: SPR-10610
These changes provide more robust handling of function
reference compilation in SpEL expressions. Prior to
this change the isCompilable check was not performing
enough visibility checks on the proposed target
function, causing bytecode to be generated that
would lead to an IllegalAccessError.
The changes also bring the argument handling for
function invocation completely inline with that used
for method invocation allowing some code to be deleted.
Many new tests are also included for function
reference compilation.
Issue: SPR-12359
Building on the initial work for SPR-12326, this commit
addresses three problems:
Firstly the ReflectiveMethodResolver is modified to consider
a direct parameter match more important than a varargs match.
Also in that same type when there are a number of close
matches, the first one is taken rather than the last one.
Secondly more testcases and better support have been added
for the case of passing a single parameter to a varargs
accepting method.
Finally it is possible to set the root context object
indirectly and not pass it on getValue() calls to the
expression objects but not all variants of getValue()
were handling that. This is now fixed.
Issue: SPR-12326
The argument processing for compiling constructor references
was very basic and this fix removes that and ensures the
comprehensive logic written for method argument processing
(under SPR-12328) is now used for both method and constructor
argument handling. This fixes the reported issue and ensures
varargs constructor references can be compiled.
This also includes a couple of small fixes for the secondary
testcase reported in SPR-12326. The first is to ensure the
right root context object is used when it is passed
to getValue() indirectly through the evaluation context.
The final fix is to ensure correct boxing of primitives is
done when a method is called upon a primitive.
Issue: SPR-12326
This change introduces support for compilation of expressions
involving inline lists, string concatenation and method
invocations where the method being invoked is declared
with a varargs parameter. It also fixes a problem with
compiling existing method invocations where the target
method is on a non public type.
Issue: SPR-12328
Juergen Hoeller
Andy Clement
Sam Brannen
Andy Clement
Stephane Nicoll
Eric Bottard
Juergen Hoeller