- 02 11月, 2016 2 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-14863
-
由 Andy Clement 提交于
For SPR-14863 we need to adjust the code generation for OpNE to use !x.equals(y) rather than x!=y. There are also further cases in the equalityCheck() code in Operator that were not being handled in the compilation case (when comparators are used for example). This latter issue also affects OpEQ. Rather than add yet more bytecode generation, both OpNE and OpEQ generateCode() methods have been simplified. The generated code now delegates to equalityCheck() in Operator which is exactly what the interpreted case does. This ensures that the compiled code continues to behave just like the interpreted case. It ensures changes to the interpreted case are automatically picked up for the compiled case. It makes the bytecode generation simpler. The benefit of compilation of SpEL expressions is to avoid slow reflective calls - that doesn't apply for a basic (in)equality test so there is no need to go crazy in bytecode gen. Issue: SPR-14863
-
- 29 8月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
-
- 05 7月, 2016 1 次提交
-
-
由 Stephane Nicoll 提交于
Issue: SPR-13188
-
- 06 5月, 2016 1 次提交
-
-
由 Andy Clement 提交于
Prior to this commit the SpEL compiler would generate bad bytecode if the left hand operand of an instanceof was a primitive or if the right hand operand was a primitive type reference. With the fixes primitives on the left hand side are now correctly boxed and special handling is in place for when the right hand side is a primitive type reference. Using a primitive type reference on the right always causes the instanceof check to return false. Additionally a guard has been added such that compilation is not allowed when the right hand side of an expression is not a type reference. If it is, for example, a variable reference that evaluates to a type reference then that cannot be expressed in bytecode so compilation is not performed. Issue: SPR-14250
-
- 25 3月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 01 3月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
-
- 12 12月, 2015 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 26 11月, 2015 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 25 11月, 2015 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 27 7月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 19 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 29 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 07 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 08 3月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 07 3月, 2015 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 19 12月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 14 11月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 25 10月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 21 10月, 2014 2 次提交
-
-
由 Andy Clement 提交于
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
-
由 Juergen Hoeller 提交于
-
- 18 10月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 17 10月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 07 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
Comprehensive revision of SpEL's bytecode generation and number handling (BigInteger support, doubleValue fallback) Issue: SPR-9913
-
- 02 10月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 07 8月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
-
- 31 7月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-
- 30 7月, 2014 2 次提交
-
-
由 Andy Clement 提交于
This commit enables the modulus operator to be compiled when it is used as part of a SpEL expression. Issue: SPR-12041
-
由 Andy Clement 提交于
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
-
- 16 7月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
Revision of SpelCompiler support, resolving a subpackage cycle through moving CodeFlow and CompilablePropertyAccessor to the main spel package Also contains explicit ClassLoader management, passed through StandardBeanExpressionResolver and SpelParserConfiguration to SpelCompiler lookup. Issue: SPR-10943
-
- 11 7月, 2014 1 次提交
-
-
由 Andy Clement 提交于
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
-