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
The ternary expression node was failing to generate the
necessary unboxing bytecode when the condition part
of the expression returned a boxed Boolean rather than
a primitive boolean.
Also fixed here is an IllegalAccessError that was
seen in the same expression due to generating a
CHECKCAST bytecode for a private type.
Issue: SPR-12271
This commit introduces the ability to specify an inline map in
an expression. The syntax is similar to inline lists and of
the form: "{key:value,key2:value}". The keys can optionally
be quoted. The documentation is also updated with information
on the syntax.
Issue: SPR-9472
There is special handling for SpEL expressions involving a map
and an unquoted string literal key (e.g. mymap[key1]). SpEL does
not require key1 to be quoted. This special handling which is done
in Indexer getValueRef() was not being also done in the Indexer
generateCode() method that compiles the expression. Also fixed
a problem where the key was not being compiled in a new
sub scope. Without the new scope the key expression was failing
to reload the relevant context object when it needed it.
Issue: SPR-12045
This commit allows the SpEL compiler to cope with generic methods
being used in expressions involving numeric operands. Due to the
use of unbound type variables the methods may look like they
return Object but in fact they are returning objects of a numeric
type that are suitable for compilation. The changes here ensure
the runtime types are looked at if the discovered declared types
are not providing enough information. This impacts all the
operands involving numerics (mathematical and relational).
Issue: SPR-12040
Also contains explicit ClassLoader management, passed through StandardBeanExpressionResolver and SpelParserConfiguration to SpelCompiler lookup.
Issue: SPR-10943
With these changes an optional compiler is added for SpEL
expressions. The compiler is off by default but can be enabled
via the SpEL parser configuration object or system property
(when SpEL is embedded and parser configuration is not possible).
Not all expressions are currently handled but the common
cases are and it is an extensible compilation framework.
Issue: SPR-10943
Clean up compiler warnings in the tests of spring-expression. This
commit adds type parameters to some of the types (mostly `List` and
`Map`). Some of them can't be cleaned up, some tests are even
specifically for raw types.
Prior to this commit, the codebase was using a mix of log4j.xml
and log4j.properties for test-related logging configuration. This
can be an issue as log4j takes the xml variant first when looking
for a default bootstrap configuration.
In practice, some modules declaring the properties variant were
taking the xml variant configuration from another module.
The general structure of the configuration has also been
harmonized to provide a standard console output as well as an
easy way to enable trace logs for the current module.
When a node of an SPeL expression was a call to a bean referenced
in a method argument, the expression was resolved twice.
The resolved arguments are now specified to MethodValueRef instead
of resolving the arguments again in the constructor
Issue: SPR-11445
Fixed through falling back to the raw parameter type in the TypeDescriptor(MethodParameter) constructor, properly detecting the vararg array even in case of an unresolvable type variable, and through restoring getElementTypeDescriptor's original behavior for arrays, i.e. always returning a non-null descriptor.
Issue: SPR-11494
- Consistent importing of org.junit.Assert.*;
- Proper declaration of expected exceptions via @Test(expected).
- Renamed SpEL ExpressionTestCase to AbstractExpressionTests.
- Formatting and test method naming conventions.
Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.
Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.
Issue: SPR-11064
Prior to this change, SpEL supported numeric operations for int, float,
ect. `new java.math.BigDecimal('0.1') > 0` evaluated to false
(BigDecimal is truncated to int)
This commit introduces support for BigDecimal operations for all
mathematical operators. `new java.math.BigDecimal('0.1') > 0` now
evaluates to true (the comparison is made with BigDecimals)
Issue: SPR-9164
Prior to this commit the SpEL operators `==` and `!=` were using the
Java `==` comparison operator as part of their equality checking. It is
more flexible to use the equals() method on Object.
Under this commit the change to .equals() has been made and the equality
checking code has been pushed into a common method in the Operator
superclass. This commit also makes some tweaks to the other operator
classes - the Float case was missing from OpGT.
Issue: SPR-9194
Update EvaluationException to expose the toDetailedString() method as
the exception message. The simple message can now be accessed via the
new getSimpleMessage() method.
Issue: SPR-10938
Update the `CacheKey` class used by `ReflectivePropertyAccessor` to
include if the target object is class. The prevents an incorrect cache
hit from being returned when a property with the same name is read on
both an object and its class. For example:
#{class.name}
#{name}
Issue: SPR-10486
Relax the method search algorithm used by `ReflectivePropertyAccessor`
to include methods of the form `getXY()` for properties of the form
`xy`.
Although the JavaBean specification indicates that a property `xy`
should use the accessors `getxY()` and `setxY()`, in practice many
developers choose to have an uppercase first character. The
`ReflectivePropertyAccessor` will now consider these style methods if
the traditional conventions fail to find a match.
Issue: SPR-10716
Juergen Hoeller
Andy Clement
Stephane Nicoll
Philippe Marschall
Sam Brannen
Stephane Nicoll
Phillip Webb
giovannidalloglio