[jira] [Comment Edited] (JEXL-430) JexlArithmetic behavior change
[
https://issues.apache.org/jira/browse/JEXL-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884501#comment-17884501
]
Henri Biestro edited comment on JEXL-430 at 9/25/24 5:53 AM:
-
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428 ) that gives you full control over the
intended behavior.
was (Author: henrib):
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428 ).
> JexlArithmetic behavior change
> --
>
> Key: JEXL-430
> URL: https://issues.apache.org/jira/browse/JEXL-430
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Fix Version/s: 3.4.1
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-430) JexlArithmetic behavior change
[
https://issues.apache.org/jira/browse/JEXL-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884501#comment-17884501
]
Henri Biestro edited comment on JEXL-430 at 9/25/24 5:49 AM:
-
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428 ).
was (Author: henrib):
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428.
> JexlArithmetic behavior change
> --
>
> Key: JEXL-430
> URL: https://issues.apache.org/jira/browse/JEXL-430
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884505#comment-17884505 ] Henri Biestro edited comment on JEXL-428 at 9/25/24 5:49 AM: - The problem with Comparable interface is that its generic nature implies the signature is compareTo(Object) which does not help disambiguate the call. The workaround is to implement your own 'public int compare(MyClass lhs, String rhs)' - or any signature you need to disambiguate - in your own derived arithmetic. Commit [2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025] was (Author: henrib): Commit [2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025] > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4.1 > > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-428. Resolution: Fixed Commit [2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025] > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4.1 > > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-429.
Resolution: Fixed
Commit
[2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025]
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884502#comment-17884502
]
Henri Biestro commented on JEXL-429:
Ternary and namespace syntax is a grammar ambiguity pothole.
To fix this, a new hint will consider if the function name (the fun in ns :
fun()) is a variable which solves this precise case.
A new feature flag is introduced, 'namespace identifier' which considers a
namespace identifier as one token that is only when 'ns:fun' is written with no
space in between. Default remains false but, as per recommendation, one should
be explicit about which feature, option, security and arithmetic is used.
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-430) JexlArithmetic behavior change
[
https://issues.apache.org/jira/browse/JEXL-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-430.
Assignee: Henri Biestro
Resolution: Workaround
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428.
> JexlArithmetic behavior change
> --
>
> Key: JEXL-430
> URL: https://issues.apache.org/jira/browse/JEXL-430
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Summary: Ternary expression regression (was: Regressions in 3.4.0)
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Description:
{*}Regression{*}:
{code:java}
const f = function(a) {return a;};
b ? b : f(2);{code}
When the script is executed, there is a variable *b* in the jexl context with
value as {*}1{*}.
The script returns 1 as expected in 3.3, but throws a parsing exception in
3.4.0.
{code:java}
parsing error in ';'
at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
{code}
If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
and 2 is returned as expected.
was:
{*}Regression #1{*}:
{code:java}
"1.1" > 0 {code}
returns *true* in 3.3. But it throws an exception in 3.4.0.
{code:java}
java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
at org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
at
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
at org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
{*}Regression #2{*}:
{code:java}
const f = function(a) {return a;};
b ? b : f(2);{code}
When the script is executed, there is a variable *b* in the jexl context with
value as {*}1{*}.
The script returns 1 as expected in 3.3, but throws a parsing exception in
3.4.0.
{code:java}
parsing error in ';'
at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
{code}
If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
and 2 is returned as expected.
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-430) JexlArithmetic behavior change
Henri Biestro created JEXL-430:
--
Summary: JexlArithmetic behavior change
Key: JEXL-430
URL: https://issues.apache.org/jira/browse/JEXL-430
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.4.0
Reporter: Henri Biestro
Fix For: 3.4.1
{*}Regression{*}:
{code:java}
"1.1" > 0 {code}
returns *true* in 3.3. But it throws an exception in 3.4.0.
{code:java}
java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
at org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
at
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
at org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Assignee: Henri Biestro
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression #1{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
> {*}Regression #2{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883891#comment-17883891
]
Henri Biestro commented on JEXL-429:
Something can be done to improve JEXL-412; a function call using a local
variable can be used as hint.
For the arithmetic new stricter behavior, the workaround would be to derive a
JexlArithmetic and add a compare(String, Number) method; need to commit
JEXL-428 related work first.
PS: 2 issues in one ticket is really inconvenient.
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Priority: Major
>
> {*}Regression #1{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
> {*}Regression #2{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883765#comment-17883765
]
Henri Biestro commented on JEXL-429:
Related to:
1/ [JEXL-420|https://issues.apache.org/jira/browse/JEXL-420]
2/ [JEXL-412|https://issues.apache.org/jira/browse/JEXL-412]
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Priority: Major
>
> {*}Regression #1{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
> {*}Regression #2{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-428: --- Assignee: Henri Biestro > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-428: --- Fix Version/s: 3.4.1 > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4.1 > > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-428: --- Affects Version/s: 3.4.0 > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-428) Make Comparable object high priority while comparing
[
https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879833#comment-17879833
]
Henri Biestro commented on JEXL-428:
The difficulty might be in respecting the expectation :{code}compare(x, y) ==
-compare(y, x){code}
The lengthy workaround would be to implement the operator methods in the
JexlArithmetic with the intended signature (public boolean lessThan(XuClass xu,
String right); public boolean greaterThan(String right, XuClass xu); etc.).
As an improvement, it could be possible to expose a compare operator
(JexlOperator.COMPARE) to only have to implement 2 methods.
Wdyt ?
> Make Comparable object high priority while comparing
>
>
> Key: JEXL-428
> URL: https://issues.apache.org/jira/browse/JEXL-428
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Priority: Major
>
> [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787]
>
> I defined a Class with implemented Comparable interface, when compare it with
> a string object, engine does not call the compareTo method but compares by
> string value.
>
> At JexlArithmetic.java L787, if one of the left/right value is string type,
> then compares by string value, I think if the left value is Comparable and
> not String type, using left object's compareTo method first makes more sense.
> Thanks!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-425) Multiline format literals does not always return string.
[
https://issues.apache.org/jira/browse/JEXL-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-425.
Resolution: Fixed
Commit
[aecb393|https://github.com/apache/commons-jexl/commit/aecb3934d3702d60c456750051374ca756f20826]
> Multiline format literals does not always return string.
>
>
> Key: JEXL-425
> URL: https://issues.apache.org/jira/browse/JEXL-425
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> For example
>
> {code:java}
> let x = 10;
> let y = `${x}` // y is integer type of 10, expect y to be string
> let z = `${x}1` // z is string '101'{code}
>
> here the type of `y` expected to be string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-426) Enable pass-by-reference for Captured Variables
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-426.
Resolution: Fixed
Commit
[aecb393|https://github.com/apache/commons-jexl/commit/aecb3934d3702d60c456750051374ca756f20826]
> Enable pass-by-reference for Captured Variables
>
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-427) Avoid coercing logical expressions to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-427.
Resolution: Fixed
3.4.1 behavior - JexlBuilder.booleanLogical(false) - make the logical
(short-circuit) expressions return the last evaluated argument.
3.4 behavior can be restored with JexlBuilder.booleanLogical(true) - belt and
suspenders -; the new default however is not expected to cause problems in the
field.
> Avoid coercing logical expressions to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.4.1
>
>
> As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> The discussion/comments below stem from the initial request:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-424.
Resolution: Fixed
Commit
[788c405|https://github.com/apache/commons-jexl/commit/788c4059eda8baf45150c2fb205793dae5c7b590]
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-424:
Regression detected...
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-425) Multiline format literals does not always return string.
[
https://issues.apache.org/jira/browse/JEXL-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-425:
---
Affects Version/s: 3.4.0
> Multiline format literals does not always return string.
>
>
> Key: JEXL-425
> URL: https://issues.apache.org/jira/browse/JEXL-425
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For example
>
> {code:java}
> let x = 10;
> let y = `${x}` // y is integer type of 10, expect y to be string
> let z = `${x}1` // z is string '101'{code}
>
> here the type of `y` expected to be string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-425) Multiline format literals does not always return string.
[
https://issues.apache.org/jira/browse/JEXL-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-425:
---
Fix Version/s: 3.4.1
> Multiline format literals does not always return string.
>
>
> Key: JEXL-425
> URL: https://issues.apache.org/jira/browse/JEXL-425
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> For example
>
> {code:java}
> let x = 10;
> let y = `${x}` // y is integer type of 10, expect y to be string
> let z = `${x}1` // z is string '101'{code}
>
> here the type of `y` expected to be string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-426) Enable pass-by-reference for Captured Variables
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-426:
---
Fix Version/s: 3.4.1
> Enable pass-by-reference for Captured Variables
>
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-426) Enable pass-by-reference for Captured Variables
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-426:
---
Affects Version/s: 3.4.0
> Enable pass-by-reference for Captured Variables
>
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-426) Enable pass-by-reference for Captured Variables
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-426:
---
Summary: Enable pass-by-reference for Captured Variables (was: Value of
Captured Variable )
> Enable pass-by-reference for Captured Variables
>
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-427) Avoid coercing logical expressions to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878188#comment-17878188
]
Henri Biestro commented on JEXL-427:
Finally, decided to add an option (booleanLogical) just to be on the safe side.
> Avoid coercing logical expressions to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.4.1
>
>
> As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> The discussion/comments below stem from the initial request:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-427) Avoid coercing logical expressions to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-427:
---
Affects Version/s: 3.4.0
> Avoid coercing logical expressions to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> The discussion/comments below stem from the initial request:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-427) Avoid coercing logical expressions to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-427:
---
Fix Version/s: 3.4.1
> Avoid coercing logical expressions to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.4.1
>
>
> As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> The discussion/comments below stem from the initial request:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-427) Avoid coercing logical expressions to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-427:
---
Description:
As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
boolean; the ask is to let the results be as is. When used as conditions, they
will be coerced to boolean by the testPredicate function anyhow; in other
cases, this allows short-circuit evaluation similar to EcmaScript.
The discussion/comments below stem from the initial request:
*Support &: operator:*
Similiar with ternary conditional `?:`, but
{code:javascript}
x &: y
{code}
equals
{code:javascript}
x ? y : x
{code}
Thanks!
was:
As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
boolean; the ask is to let the results be as is. When used as conditions, they
will be coerced to boolean by the testPredicate function anyhow; in other
cases, this allows short-circuit evaluation similar to EcmaScript.
initial demand:
*Support &: operator:*
Similiar with ternary conditional `?:`, but
{code:javascript}
x &: y
{code}
equals
{code:javascript}
x ? y : x
{code}
Thanks!
> Avoid coercing logical expressions to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> The discussion/comments below stem from the initial request:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-427) Avoid coercing logical expressions to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-427:
---
Description:
As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
boolean; the ask is to let the results be as is. When used as conditions, they
will be coerced to boolean by the testPredicate function anyhow; in other
cases, this allows short-circuit evaluation similar to EcmaScript.
initial demand:
*Support &: operator:*
Similiar with ternary conditional `?:`, but
{code:javascript}
x &: y
{code}
equals
{code:javascript}
x ? y : x
{code}
Thanks!
was:
As of JEXL 3.4, logical expression (&& , ||) are coercing their results to
boolean; the ask is to let the results be as is. When used as conditions, they
will be coerced to boolean by the testPredicate function anyhow; in other
cases, this allows short-circuit evaluation similar to EcmaScript.
initial demand:
*Support &: operator:*
Similiar with ternary conditional `?:`, but
{code:javascript}
x &: y
{code}
equals
{code:javascript}
x ? y : x
{code}
Thanks!
> Avoid coercing logical expressions to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> As of JEXL 3.4, logical expressions (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> initial demand:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-427) Avoid coercing logical expressions results to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-427:
---
Description:
As of JEXL 3.4, logical expression (&& , ||) are coercing their results to
boolean; the ask is to let the results be as is. When used as conditions, they
will be coerced to boolean by the testPredicate function anyhow; in other
cases, this allows short-circuit evaluation similar to EcmaScript.
initial demand:
*Support &: operator:*
Similiar with ternary conditional `?:`, but
{code:javascript}
x &: y
{code}
equals
{code:javascript}
x ? y : x
{code}
Thanks!
was:
Similiar with ternary conditional `?:`, but
{code:javascript}
x &: y
{code}
equals
{code:javascript}
x ? y : x
{code}
Thanks!
Summary: Avoid coercing logical expressions results to boolean (was:
Support &: operator)
> Avoid coercing logical expressions results to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> As of JEXL 3.4, logical expression (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> initial demand:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-427) Avoid coercing logical expressions to boolean
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-427:
---
Summary: Avoid coercing logical expressions to boolean (was: Avoid
coercing logical expressions results to boolean)
> Avoid coercing logical expressions to boolean
> -
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> As of JEXL 3.4, logical expression (&& , ||) are coercing their results to
> boolean; the ask is to let the results be as is. When used as conditions,
> they will be coerced to boolean by the testPredicate function anyhow; in
> other cases, this allows short-circuit evaluation similar to EcmaScript.
> initial demand:
> *Support &: operator:*
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-427) Support &: operator
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877787#comment-17877787
]
Henri Biestro commented on JEXL-427:
In the vast majority of usage, logical expressions are used as conditions in
if/for/while (and now ternary) which coerce their argument to boolean (which
was redundant) through a call to JexlArithmetic.testPredicate().
For the odd case where one needs to explicitly coerce such an expression to
boolean for any other purpose, the !! (double negate) will achieve just that.
Adding an option (booleanShortCircuit) to guarantee compatibility almost seems
like clutter (for now).
> Support &: operator
> ---
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-425) Multiline format literals does not always return string.
[
https://issues.apache.org/jira/browse/JEXL-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877119#comment-17877119
]
Henri Biestro commented on JEXL-425:
Prototyping using an option flag (strictInterpolation) that, when true,
enforces interpolation expressions (`${...}`) return a string on evaluation.
More tests required.
> Multiline format literals does not always return string.
>
>
> Key: JEXL-425
> URL: https://issues.apache.org/jira/browse/JEXL-425
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For example
>
> {code:java}
> let x = 10;
> let y = `${x}` // y is integer type of 10, expect y to be string
> let z = `${x}1` // z is string '101'{code}
>
> here the type of `y` expected to be string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-426) Value of Captured Variable
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877116#comment-17877116
]
Henri Biestro commented on JEXL-426:
Prototyping using a feature flag (referenceCapture) that (statically, at
parsing time) transforms any captured variable into a shared reference; during
execution, whenever a captured variable is set/get, it updates/accesses the
referenced value. More tests will be required.
> Value of Captured Variable
> ---
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-427) Support &: operator
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877114#comment-17877114
]
Henri Biestro commented on JEXL-427:
Better yet, make && and || perform short-circuit evaluation and return the
latest eval (the first truthy for ||, the first falsy for &&); this should
match the expected behavior.
> Support &: operator
> ---
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-427) Support &: operator
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876784#comment-17876784
]
Henri Biestro commented on JEXL-427:
My bad, you're right. It might be more efficient to allow overloads of those
rather than introduce another syntax. I'll give it a try and see.
> Support &: operator
> ---
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-426) Value of Captured Variable
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876778#comment-17876778
]
Henri Biestro commented on JEXL-426:
When you say 'synced between captured value and source', you actually refer to
being able to manipulate variables as reference rather than as value.
Besides having potentially surprising effects - calling the same lambda twice
or in parallel may not lead to the same result since side-effects on captured
variables will have shared scope -, this is a behavior change that would break
existing scripts. This will need a (yet another feature) flag and likely
require a type of reference and/or annotation.
> Value of Captured Variable
> ---
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-427) Support &: operator
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876762#comment-17876762
]
Henri Biestro commented on JEXL-427:
Why don't you override the arithmetic methods and()/or() then ?
> Support &: operator
> ---
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-426) Value of Captured Variable
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876761#comment-17876761
]
Henri Biestro commented on JEXL-426:
You mean you'd want captured variables to be const (the same way they are final
in Java) ?
> Value of Captured Variable
> ---
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-425) Multiline format literals does not always return string.
[
https://issues.apache.org/jira/browse/JEXL-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876654#comment-17876654
]
Henri Biestro commented on JEXL-425:
We will have to protect this behavior change with some flag since it is very
likely this bug has been exploited in the field.
Typically, if a is a map keyed by integers, an expression like
{code:java}a.`${b}`{code} will cease to return the expected value since the key
will be coerced to String (and "1" != 1).
> Multiline format literals does not always return string.
>
>
> Key: JEXL-425
> URL: https://issues.apache.org/jira/browse/JEXL-425
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For example
>
> {code:java}
> let x = 10;
> let y = `${x}` // y is integer type of 10, expect y to be string
> let z = `${x}1` // z is string '101'{code}
>
> here the type of `y` expected to be string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-425) Multiline format literals does not always return string.
[
https://issues.apache.org/jira/browse/JEXL-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-425:
---
Assignee: Henri Biestro
> Multiline format literals does not always return string.
>
>
> Key: JEXL-425
> URL: https://issues.apache.org/jira/browse/JEXL-425
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For example
>
> {code:java}
> let x = 10;
> let y = `${x}` // y is integer type of 10, expect y to be string
> let z = `${x}1` // z is string '101'{code}
>
> here the type of `y` expected to be string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-427) Support &: operator
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876651#comment-17876651
]
Henri Biestro commented on JEXL-427:
Very reluctant to even consider this addendum which seems to have a very low
added value (if any) wrt maintainability; is there any language that supports
that construct ?
> Support &: operator
> ---
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-427) Support &: operator
[
https://issues.apache.org/jira/browse/JEXL-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-427:
---
Assignee: Henri Biestro
> Support &: operator
> ---
>
> Key: JEXL-427
> URL: https://issues.apache.org/jira/browse/JEXL-427
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
>
> Similiar with ternary conditional `?:`, but
> {code:javascript}
> x &: y
> {code}
> equals
> {code:javascript}
> x ? y : x
> {code}
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-426) Value of Captured Variable
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876643#comment-17876643
]
Henri Biestro edited comment on JEXL-426 at 8/26/24 9:25 AM:
-
The current behavior- ie the capture happens at definition time - should not be
altered.
However, if you want the captured variable to be a reference rather than a
value, you may want to check Optional/JEXL-342.
As a crude example of reference:
{code}
@Test public void test426() {
String src = "let x = [10];\n" +
"function foo() {\n" +
"x[0] += 2;\n" +
"}\n" +
"x[0] = 40;\n" +
"foo();\n" +
"x[0]";
final JexlBuilder builder = new JexlBuilder().features(new
JexlFeatures().constCapture(true));
final JexlEngine jexl = builder.create();
JexlScript script;
Object result;
script = jexl.createScript(src);
result = script.execute(null);
assertEquals(42, result);
}
{code}
was (Author: henrib):
The current behavior- ie the capture happens at definition time - should not be
altered.
However, if you want the captured variable to be a reference rather than a
value, you may want to check Optional/JEXL-342.
> Value of Captured Variable
> ---
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-426) Value of Captured Variable
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876643#comment-17876643
]
Henri Biestro commented on JEXL-426:
The current behavior- ie the capture happens at definition time - should not be
altered.
However, if you want the captured variable to be a reference rather than a
value, you may want to check Optional/JEXL-342.
> Value of Captured Variable
> ---
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-426) Value of Captured Variable
[
https://issues.apache.org/jira/browse/JEXL-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-426:
---
Assignee: Henri Biestro
> Value of Captured Variable
> ---
>
> Key: JEXL-426
> URL: https://issues.apache.org/jira/browse/JEXL-426
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> For the code
> {code:java}
> let x = 10;
> function foo() {
> x += 2;
> }
> foo();
> return x;{code}
> By default the return value of x is 10 because `x` inside `foo` is a captured
> value, re-assign value not affect the variable outside `foo`, which some
> times confuse the developer, therefore a new feature `constCapture` was
> introduced to prevent such kind of re-assignment, which is the same behavior
> of Java code.
> But the problem is variable `x` outside of function is not const, for the
> following code
>
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:someCall(x);
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; {code}
> This code is valid with constCapture = true (similar code in java is invalid
> because x needs to be 'final'), but the value inside `foo` is 10, not 20, I
> checked the JEXL source codes and found the value inside `foo` is captured
> when defining `foo` function (line 3), which is 10, even when calling `foo`
> in line 6 the value of x is already be 20, this case is also somehow confuse.
>
> I tried extending Interpreter to change the behavior of captured variable to:
> # re-assign the captured variable to latest value from parent frame before
> executing.
> # populate the value to parent scope while assigning new value to a captured
> variable
> with this interpreter, the value of x in line 3 and 7 are 22, which I think
> is more easy to understand.
> {code:java}
> 1: let x = 10;
> 2: function foo() {
> 3:x += 2; // here x = 22
> 4: }
> 5: x = 20;
> 6: foo();
> 7: return x; // here x = 22{code}
>
> Is it possible to add a new feature to support this behavior?
> or provide more apis, i.e.
> # api to get whole frame stack (now I store it in JexlContext)
> # read/write value by variable name for a frame (now I reflect the
> get/set/getSymbol methods of Frame class)
> # get parent of Scope.
> Thanks very much!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-424.
Resolution: Fixed
Code was indeed dependent on permission lookup order since it was only checking
the permission cache; fix is to compute permission fully on a 'get' (if not
cached).
That being said, the new framework
org.apache.commons.jexl3.introspection.JexlPermissions is now the preferred way
to secure applications and restrict class/method/fields visibility.
Commit
[78b3dd9|https://github.com/apache/commons-jexl/commit/78b3dd90f07d86531c8c99f6f9b5bea00bea8205]
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-424:
---
Assignee: Henri Biestro
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-424) Permission error after upgraded to JDK 21
[
https://issues.apache.org/jira/browse/JEXL-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-424:
---
Fix Version/s: 3.4.1
> Permission error after upgraded to JDK 21
> -
>
> Key: JEXL-424
> URL: https://issues.apache.org/jira/browse/JEXL-424
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {code:java}
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(Map.class.getName(), true, true, true, true);
> ...
> String jexlCode = "x.foo = 'bar';"
> JexlEngine engine =
> new Engine(
> new JexlBuilder()
> .sandbox(sandbox)
> .safe(false)
> .strict(true));
> Map vars = new LinkedHashMap<>();
> vars.put("x", new LinkedHashMap<>());
> engine.createScript(jexlCode).execute(new MapContext(vars)); {code}
> The code is ok with JDK11, but caused an error "undefined property 'foo'"
> with JDK21.
>
> I did some debug and found the problem is
> JDK11: LinkedHashMap implements Map
> JDK21: LinkedHashMap implements SequencedMap extends Map
> and from
> [JexlSandbox.java#L540|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/introspection/JexlSandbox.java#L540]]
> {code:java}
> for (final Class inter : clazz.getInterfaces()) {
> permissions = sandbox.get(inter.getName());
> if (permissions != null) {
> if (permissions.isInheritable()) {
> break;
> }
> permissions = null;
> }
> } {code}
> sandbox only checks the direct interfaces but not check it's super interface,
> but for class permission check, it looks into its parents, is it by design or
> a bug?
>
> And also because which checking permission of class, it does not check it's
> interface's permission, the result of class is not stable in case parent
> class has permission from it's interface.
> for example:
> {code:java}
> interface I{}
> static class A implements I{}
> static class B extends A{}
> @Test
> void testPermission() {
> JexlSandbox sandbox = new JexlSandbox(false, true);
> sandbox.permissions(I.class.getName(), true, true, true, false);
> System.out.println("permission A=" +
> sandbox.get(A.class.getName()).write());
> System.out.println("permission B=" +
> sandbox.get(B.class.getName()).write());
> }
> {code}
> result is
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> permission
> B=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@31e04b13
> but if checking B befoer A, the result is
> permission B=org.apache.commons.jexl3.introspection.JexlSandbox$2@6c1832aa
> permission
> A=org.apache.commons.jexl3.introspection.JexlSandbox$AllowSet@47ad69f7
>
> Maybe we need to travel the whole inheritance tree and also need a merge
> policy for multiple permission definitions?
>
> BTW, what is the release date for next version? thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-422) Add strict equality (===) and inequality (!==) operators
[ https://issues.apache.org/jira/browse/JEXL-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-422. Resolution: Fixed [Commited|https://github.com/apache/commons-jexl/commit/b640ba6820eb07ffc23043f118a3497f64339df5] > Add strict equality (===) and inequality (!==) operators > > > Key: JEXL-422 > URL: https://issues.apache.org/jira/browse/JEXL-422 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.4 > > > As in Javascript, === is a comparison operator that checks the equality of > two values without performing any type conversion. This means that if the > values being compared have different data types, === will return false. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-423) Add support for instanceof / !instanceof
[
https://issues.apache.org/jira/browse/JEXL-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-423.
Resolution: Fixed
[Commited|https://github.com/apache/commons-jexl/commit/b640ba6820eb07ffc23043f118a3497f64339df5]
> Add support for instanceof / !instanceof
>
>
> Key: JEXL-423
> URL: https://issues.apache.org/jira/browse/JEXL-423
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.4
>
>
> The *instanceof* operator allows to check whether an object belongs to a
> certain class.
> It is using Class.isInstance to perform the check. As a convenience, {{
> !instanceof }} is supported as well avoiding parenthesis as in:
> {code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
> y){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-396) Add explicit Java module descriptor
[ https://issues.apache.org/jira/browse/JEXL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-396. Resolution: Fixed > Add explicit Java module descriptor > --- > > Key: JEXL-396 > URL: https://issues.apache.org/jira/browse/JEXL-396 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Andres Almiray >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > Follow up from a > [topic|https://lists.apache.org/thread/kxcwqyx026rhhx4v8q8bkbljj7lw8c32] > started at the mailing list. > Henri suggested using the ModiTect plugin guarded by a profile with JDK > activation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-235) Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before release
[
https://issues.apache.org/jira/browse/JEXL-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849306#comment-17849306
]
Henri Biestro commented on JEXL-235:
Checked [3.4|
https://github.com/apache/commons-jexl/commit/b640ba6820eb07ffc23043f118a3497f64339df5].
> Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before
> release
> ---
>
> Key: JEXL-235
> URL: https://issues.apache.org/jira/browse/JEXL-235
> Project: Commons JEXL
> Issue Type: Task
>Affects Versions: 3.2
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: Later
>
>
> JexlScriptEngineFactory.getLanguageVersion and
> JexlScriptEngineFactory.getEngine version should reflect the syntax version
> and the engine version respectively.
> As a rule, any new operator or syntax should bump the language version, any
> release should update the engine version that should match the jar version.
> (see JEXL-227 for discussion on the issue).
> This task must be checked for each version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-397) Dynamic proxy should not require specific permission
[
https://issues.apache.org/jira/browse/JEXL-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-397:
---
Fix Version/s: 3.3.1
(was: 3.4)
> Dynamic proxy should not require specific permission
>
>
> Key: JEXL-397
> URL: https://issues.apache.org/jira/browse/JEXL-397
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> With the default restricted permissions, dynamic proxies can not be
> introspected since they extend java.lang.reflect.Proxy whose package is
> denied.
> A workaround is to explicitly allow them as in:
> {code:java}
> JexlPermissions p = new JexlPermissions.Delegate(JexlPermissions.RESTRICTED) {
> @Override public boolean allow(Class clazz) {
> return Proxy.isProxyClass(clazz) || super.allow(clazz);
> }
> };
> {code}
> This workaround should not be necessary.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-396) Add explicit Java module descriptor
[ https://issues.apache.org/jira/browse/JEXL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-396: --- Fix Version/s: 3.3.1 (was: 3.4) > Add explicit Java module descriptor > --- > > Key: JEXL-396 > URL: https://issues.apache.org/jira/browse/JEXL-396 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Andres Almiray >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > Follow up from a > [topic|https://lists.apache.org/thread/kxcwqyx026rhhx4v8q8bkbljj7lw8c32] > started at the mailing list. > Henri suggested using the ModiTect plugin guarded by a profile with JDK > activation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-396) Add explicit Java module descriptor
[ https://issues.apache.org/jira/browse/JEXL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-396: --- Fix Version/s: 3.4 > Add explicit Java module descriptor > --- > > Key: JEXL-396 > URL: https://issues.apache.org/jira/browse/JEXL-396 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Andres Almiray >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4 > > > Follow up from a > [topic|https://lists.apache.org/thread/kxcwqyx026rhhx4v8q8bkbljj7lw8c32] > started at the mailing list. > Henri suggested using the ModiTect plugin guarded by a profile with JDK > activation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-423) Add support for instanceof / !instanceof
[
https://issues.apache.org/jira/browse/JEXL-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-423:
---
Description:
The *instanceof* operator allows to check whether an object belongs to a
certain class.
It is using Class.isInstance to perform the check. As a convenience, {{
!instanceof }} is supported as well avoiding parenthesis as in:
{code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
y){code}
was:
The {code:java} instanceof {code}
operator allows to check whether an object belongs to a certain class.
It is using Class.isInstance to perform the check. As a convenience, {{
!instanceof }} is supported as well avoiding parenthesis as in:
{code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
y){code}
> Add support for instanceof / !instanceof
>
>
> Key: JEXL-423
> URL: https://issues.apache.org/jira/browse/JEXL-423
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> The *instanceof* operator allows to check whether an object belongs to a
> certain class.
> It is using Class.isInstance to perform the check. As a convenience, {{
> !instanceof }} is supported as well avoiding parenthesis as in:
> {code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
> y){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-423) Add support for instanceof / !instanceof
[
https://issues.apache.org/jira/browse/JEXL-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-423:
---
Description:
The {code:java} instanceof {code}
operator allows to check whether an object belongs to a certain class.
It is using Class.isInstance to perform the check. As a convenience, {{
!instanceof }} is supported as well avoiding parenthesis as in:
{code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
y){code}
was:
The {{instanceof}} operator allows to check whether an object belongs to a
certain class.
It is using Class.isInstance to perform the check. As a convenience,
{{!instanceof}} is supported as well avoiding parenthesis as in:
{{x !instanceof y}} is equivalent to {{!(x instanceof y)}}
> Add support for instanceof / !instanceof
>
>
> Key: JEXL-423
> URL: https://issues.apache.org/jira/browse/JEXL-423
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> The {code:java} instanceof {code}
> operator allows to check whether an object belongs to a certain class.
> It is using Class.isInstance to perform the check. As a convenience, {{
> !instanceof }} is supported as well avoiding parenthesis as in:
> {code:java}x !instanceof y{code} is equivalent to {code:java} !(x instanceof
> y){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-423) Add support for instanceof / !instanceof
Henri Biestro created JEXL-423:
--
Summary: Add support for instanceof / !instanceof
Key: JEXL-423
URL: https://issues.apache.org/jira/browse/JEXL-423
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.3
Reporter: Henri Biestro
Assignee: Henri Biestro
Fix For: 3.3.1
The {{instanceof}} operator allows to check whether an object belongs to a
certain class.
It is using Class.isInstance to perform the check. As a convenience,
{{!instanceof}} is supported as well avoiding parenthesis as in:
{{x !instanceof y}} is equivalent to {{!(x instanceof y)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-422) Add strict equality (===) and inequality (!==) operators
Henri Biestro created JEXL-422: -- Summary: Add strict equality (===) and inequality (!==) operators Key: JEXL-422 URL: https://issues.apache.org/jira/browse/JEXL-422 Project: Commons JEXL Issue Type: New Feature Affects Versions: 3.3 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 3.3.1 As in Javascript, === is a comparison operator that checks the equality of two values without performing any type conversion. This means that if the values being compared have different data types, === will return false. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-418) Add try-catch support
[ https://issues.apache.org/jira/browse/JEXL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-418. Fix Version/s: 3.3.1 Resolution: Fixed Merged [b7f7201|https://github.com/apache/commons-jexl/commit/b7f720162deda73c273cb2668e1433fe82b37b65] > Add try-catch support > - > > Key: JEXL-418 > URL: https://issues.apache.org/jira/browse/JEXL-418 > Project: Commons JEXL > Issue Type: New Feature >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.3.1 > > > Hi, > Is it possible to add try-catch support? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-418) Add try-catch support
[ https://issues.apache.org/jira/browse/JEXL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818106#comment-17818106 ] Henri Biestro commented on JEXL-418: Development started in [JEXL-418|https://github.com/apache/commons-jexl/tree/JEXL-418] Syntax is in (try/try-with-resource/catch/finally); only one catch clause. More tests to follow. > Add try-catch support > - > > Key: JEXL-418 > URL: https://issues.apache.org/jira/browse/JEXL-418 > Project: Commons JEXL > Issue Type: New Feature >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Minor > > Hi, > Is it possible to add try-catch support? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-418) Add try-catch support
[ https://issues.apache.org/jira/browse/JEXL-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-418: --- Assignee: Henri Biestro > Add try-catch support > - > > Key: JEXL-418 > URL: https://issues.apache.org/jira/browse/JEXL-418 > Project: Commons JEXL > Issue Type: New Feature >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Minor > > Hi, > Is it possible to add try-catch support? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-421) ArrayBuilder: array type should reflect common class of its entries
[ https://issues.apache.org/jira/browse/JEXL-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-421. Resolution: Fixed Commit [b10477e|https://github.com/apache/commons-jexl/commit/b10477ec25c7b7ed52e58aca30e8ab3c940eeaa9] > ArrayBuilder: array type should reflect common class of its entries > --- > > Key: JEXL-421 > URL: https://issues.apache.org/jira/browse/JEXL-421 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.3.1 > > > WHAT: > The ArrayBuilder (used on syntax like [1,3,5]) tries hard to unbox if > possible (Integer to int) or keep Number as common class but falls short of > strong typing for other classes. > It would be convenient to type arrays using the strongest (in sense of > abstraction) common class from the entries. > HOW: > When detecting entry class mismatch (and not a unboxing or Number), find > better common class; Object class should only be last resort. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-421) ArrayBuilder: array type should reflect common class of its entries
Henri Biestro created JEXL-421: -- Summary: ArrayBuilder: array type should reflect common class of its entries Key: JEXL-421 URL: https://issues.apache.org/jira/browse/JEXL-421 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.3 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 3.3.1 WHAT: The ArrayBuilder (used on syntax like [1,3,5]) tries hard to unbox if possible (Integer to int) or keep Number as common class but falls short of strong typing for other classes. It would be convenient to type arrays using the strongest (in sense of abstraction) common class from the entries. HOW: When detecting entry class mismatch (and not a unboxing or Number), find better common class; Object class should only be last resort. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815979#comment-17815979
]
Henri Biestro edited comment on JEXL-420 at 2/9/24 9:09 AM:
* Added specific CoercionException (subclass of ArithmeticException) to be
ignored during comparisons to allow fall through.
* Throw CoercionException from parse\{Number*} methods.
* Added consistency in treating NaN and '' in all cases
* Avoid going through parse(value.toString()) since type system is (seems)
stable enough
Commit
[f5bf27ca|https://github.com/apache/commons-jexl/commit/f5bf27caaf7c577ed039232e5db81bcb835bc228]
was (Author: henrib):
Commit
[f5bf27ca|https://github.com/apache/commons-jexl/commit/f5bf27caaf7c577ed039232e5db81bcb835bc228]
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-420.
Resolution: Fixed
Commit
[f5bf27ca|https://github.com/apache/commons-jexl/commit/f5bf27caaf7c577ed039232e5db81bcb835bc228]
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-420:
---
Fix Version/s: 3.3.1
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-420:
---
Affects Version/s: 3.3
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-420:
---
Assignee: Henri Biestro
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815639#comment-17815639
]
Henri Biestro commented on JEXL-420:
You are right; it makes more sense to follow the Java convention. The type
system is already lenient so it might as well be convenient and coherent.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815391#comment-17815391
]
Henri Biestro edited comment on JEXL-420 at 2/7/24 6:24 PM:
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method:
{code:java}
public double toDouble(final Object val){code}
so it returns NaN when encountering a String.
Alternatively, you could override:
{code:java}
protected int compare(final Object left, final Object right, final JexlOperator
operator) {
try {
return super.compare(left, right, operator);
} catch(ArithmeticException xa) {
if (EQ.equals(operator)) {
return Integer.MAX_VALUE;
}
throw xa;
}
}{code}
to return a comparison value leading to false for the operator when catching an
ArithmeticException.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
was (Author: henrib):
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method:
{code:java}
public double toDouble(final Object val){code}
so it returns NaN when encountering a String.
Alternatively, you could override:
{code:java}
protected int compare(final Object left, final Object right, final JexlOperator
operator){code}
to return a comparison value leading to false for the operator when catching an
ArithmeticException.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815391#comment-17815391
]
Henri Biestro edited comment on JEXL-420 at 2/7/24 6:14 PM:
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method:
{code:java}
public double toDouble(final Object val){code}
so it returns NaN when encountering a String.
Alternatively, you could override:
{code:java}
protected int compare(final Object left, final Object right, final JexlOperator
operator){code}
to return a comparison value leading to false for the operator when catching an
ArithmeticException.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
was (Author: henrib):
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method {code}public double
toDouble(final Object val){code} so it returns NaN when encountering a String.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-420) Error while comparing float and string value
[
https://issues.apache.org/jira/browse/JEXL-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815391#comment-17815391
]
Henri Biestro commented on JEXL-420:
It is always possible to use an arithmetic (ie a JexlArithmetic derived class)
of your choosing.
In your case, you might want to override the method {code}public double
toDouble(final Object val){code} so it returns NaN when encountering a String.
As for the general case, I'd rather not weaken the type system; the empty
string is already an (historic) convenient exception.
> Error while comparing float and string value
>
>
> Key: JEXL-420
> URL: https://issues.apache.org/jira/browse/JEXL-420
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: Xu Pengcheng
>Priority: Major
>
> code:
> {code:java}
> 1.2 == ''{code}
> returns false
>
> code:
> {code:java}
> 1.2 == 'a'{code}
> causes exception
> {code:java}
> Caused by: java.lang.ArithmeticException: Double coercion: (a){code}
>
> Is it possible to check the right side is a number like string and return
> false if not?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-419) Add permission syntax to allow class/method/field
[
https://issues.apache.org/jira/browse/JEXL-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-419.
Resolution: Fixed
Commit
[1aeec98|https://github.com/apache/commons-jexl/commit/1aeec98893992c799b42fcca7cb1a914a250b33e]
> Add permission syntax to allow class/method/field
> -
>
> Key: JEXL-419
> URL: https://issues.apache.org/jira/browse/JEXL-419
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> WHAT
> The class permissions can only deny access to methods/fields. It is
> cumbersome to use when only a few methods need to be allowed. Adding a syntax
> to explicitly allow class members would also enable easier composition from
> the RESTRICTED permissions.
> HOW
> Add a +/- (default is -) in front of class name in permissions for the parser
> to determine whether an allow or deny set is to be created.
> Example:
> {code}
> final String src = "java.lang { +Class { getName(); getSimpleName(); } }";
> final JexlPermissions p = RESTRICTED.compose(src);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-419) Add permission syntax to allow class/method/field
Henri Biestro created JEXL-419:
--
Summary: Add permission syntax to allow class/method/field
Key: JEXL-419
URL: https://issues.apache.org/jira/browse/JEXL-419
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.3
Reporter: Henri Biestro
Fix For: 3.3.1
WHAT
The class permissions can only deny access to methods/fields. It is cumbersome
to use when only a few methods need to be allowed. Adding a syntax to
explicitly allow class members would also enable easier composition from the
RESTRICTED permissions.
HOW
Add a +/- (default is -) in front of class name in permissions for the parser
to determine whether an allow or deny set is to be created.
Example:
{code}
final String src = "java.lang { +Class { getName(); getSimpleName(); } }";
final JexlPermissions p = RESTRICTED.compose(src);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-419) Add permission syntax to allow class/method/field
[
https://issues.apache.org/jira/browse/JEXL-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-419:
---
Assignee: Henri Biestro
> Add permission syntax to allow class/method/field
> -
>
> Key: JEXL-419
> URL: https://issues.apache.org/jira/browse/JEXL-419
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> WHAT
> The class permissions can only deny access to methods/fields. It is
> cumbersome to use when only a few methods need to be allowed. Adding a syntax
> to explicitly allow class members would also enable easier composition from
> the RESTRICTED permissions.
> HOW
> Add a +/- (default is -) in front of class name in permissions for the parser
> to determine whether an allow or deny set is to be created.
> Example:
> {code}
> final String src = "java.lang { +Class { getName(); getSimpleName(); } }";
> final JexlPermissions p = RESTRICTED.compose(src);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (JEXL-398) Allow 'trailing commas' or ellipsis while defining array, map and set literals
[ https://issues.apache.org/jira/browse/JEXL-398 ]
Henri Biestro deleted comment on JEXL-398:
was (Author: garydgregory):
The build is red.
> Allow 'trailing commas' or ellipsis while defining array, map and set literals
> --
>
> Key: JEXL-398
> URL: https://issues.apache.org/jira/browse/JEXL-398
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> Allowing trailing commas in structured literals (array, set, map) as a
> convenient syntactic leniency. :)
> {code:java}
> let m = { "foo": 1, "bar": 2, };
> let a = [ 1, 2, ];
> let s = (1, 2, );{code}
> Using a trailing ellipsis (...) to alter the concrete class materialized as a
> convenient semantic shortcut.
> {code:java}
> let m = { "foo": 1, "bar": 2, ... }; // LinkedHashMap
> let a = [ 1, 2, ...]; // ArrayList
> let s = (1, 2, ...); // LinkedHashSet{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-398) Allow 'trailing commas' or ellipsis while defining array, map and set literals
[
https://issues.apache.org/jira/browse/JEXL-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-398.
Resolution: Fixed
Commit
[ca55aa8e|https://github.com/apache/commons-jexl/commit/ca55aa8e9ad4265e4a764ac3c7eab8f057bd5e1c]
Many thanks to Vincent for catching and fixing those :)
> Allow 'trailing commas' or ellipsis while defining array, map and set literals
> --
>
> Key: JEXL-398
> URL: https://issues.apache.org/jira/browse/JEXL-398
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> Allowing trailing commas in structured literals (array, set, map) as a
> convenient syntactic leniency. :)
> {code:java}
> let m = { "foo": 1, "bar": 2, };
> let a = [ 1, 2, ];
> let s = (1, 2, );{code}
> Using a trailing ellipsis (...) to alter the concrete class materialized as a
> convenient semantic shortcut.
> {code:java}
> let m = { "foo": 1, "bar": 2, ... }; // LinkedHashMap
> let a = [ 1, 2, ...]; // ArrayList
> let s = (1, 2, ...); // LinkedHashSet{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (JEXL-398) Allow 'trailing commas' or ellipsis while defining array, map and set literals
[
https://issues.apache.org/jira/browse/JEXL-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-398:
* Dot-expressions are no longer accepted as map keys;
* [,...] is no longer accepted;
* array/set/map builders never receive the extended argument
> Allow 'trailing commas' or ellipsis while defining array, map and set literals
> --
>
> Key: JEXL-398
> URL: https://issues.apache.org/jira/browse/JEXL-398
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> Allowing trailing commas in structured literals (array, set, map) as a
> convenient syntactic leniency. :)
> {code:java}
> let m = { "foo": 1, "bar": 2, };
> let a = [ 1, 2, ];
> let s = (1, 2, );{code}
> Using a trailing ellipsis (...) to alter the concrete class materialized as a
> convenient semantic shortcut.
> {code:java}
> let m = { "foo": 1, "bar": 2, ... }; // LinkedHashMap
> let a = [ 1, 2, ...]; // ArrayList
> let s = (1, 2, ...); // LinkedHashSet{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-412.
Resolution: Fixed
- Kinda restored previous behavior by looking at the whole ns:func sequence and
adding a grammar disambiguation for map entries.
Commit
[5072cd|https://github.com/apache/commons-jexl/commit/5072cdd36c1e80e0889f24133606a8cf6d7d4fe7]
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (JEXL-412) Ambiguous syntax between namespace function call and map object definition.
[
https://issues.apache.org/jira/browse/JEXL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-412:
Some people experience regressions; modules in particular declare namespaces.
> Ambiguous syntax between namespace function call and map object definition.
> ---
>
> Key: JEXL-412
> URL: https://issues.apache.org/jira/browse/JEXL-412
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Xu Pengcheng
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3.1
>
>
> {code:java}
> function test() {
> return 'x';
> }
> let var1 = 'var1';
> let x = {
> var1: test(),
> 'var2': 1
> } {code}
> this code caused a parse error.
> Looks like the reason is the parser consider `var1: test()` as a namespace
> function call but here I just want define a map keyed by variable.
> Is it possible to disable 'namespace' feature to avoid this ambiguous syntax?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790946#comment-17790946 ] Henri Biestro commented on JEXL-414: As with any benchmark, I'd take the result with a grain of salt. :-) A tight loop of 500 create/execute of a constant script definitely biases the result by emphasizing cache performance wrt actual code parsing/execution. Anyhow, the code as is allows you to choose. Since you must create a JexlBuilder and set a few options to use JEXL, you might as well take that opportunity to use the cache implementation you want. Add the eventual dependency to your project, copy the ConcurrentCache code from JEXL test to some of your packages and you're good to go. > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-417.
Assignee: Henri Biestro
Resolution: Fixed
Commit
[5ab46d|https://github.com/apache/commons-jexl/commit/5ab46d9935c992eab7ab7dce4f1fde196976c789]
and
[d894074||https://github.com/apache/commons-jexl/commit/d894074fb485c8f23ca5111ad1470dc6018bc9fb]
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790745#comment-17790745
]
Henri Biestro edited comment on JEXL-417 at 11/28/23 8:45 PM:
--
Commit
[5ab46d|https://github.com/apache/commons-jexl/commit/5ab46d9935c992eab7ab7dce4f1fde196976c789]
and
[d894074|https://github.com/apache/commons-jexl/commit/d894074fb485c8f23ca5111ad1470dc6018bc9fb]
was (Author: henrib):
Commit
[5ab46d|https://github.com/apache/commons-jexl/commit/5ab46d9935c992eab7ab7dce4f1fde196976c789]
and
[d894074||https://github.com/apache/commons-jexl/commit/d894074fb485c8f23ca5111ad1470dc6018bc9fb]
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-414. Resolution: Fixed > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-417:
---
Description:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
See
[discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
{code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
User intent about precision should be maintained.
was:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
See
[discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
{code:java}
(56.1B - 12) / 12 = 3.6B != 3
{code}
User intent about precision should be maintained.
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}(56.1B - 12) / 12 = 3.6B != 3{code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
[
https://issues.apache.org/jira/browse/JEXL-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-417:
---
Description:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
See
[discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
{code:java}
(56.1B - 12) / 12 = 3.6B != 3
{code}
User intent about precision should be maintained.
was:
When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
convert it to double/long during arithmetic operator execution leading to
unexpected results.
(56.1B - 12) / 12 = 3.6
User intent about precision should be maintained.
> JexlArithmetic looses precision during arithmetic operator execution
>
>
> Key: JEXL-417
> URL: https://issues.apache.org/jira/browse/JEXL-417
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and
> convert it to double/long during arithmetic operator execution leading to
> unexpected results.
> See
> [discussion|https://lists.apache.org/thread/h673m554ncjg06f5pqhjjtvy1qk3o2jt]
> {code:java}
> (56.1B - 12) / 12 = 3.6B != 3
> {code}
> User intent about precision should be maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-417) JexlArithmetic looses precision during arithmetic operator execution
Henri Biestro created JEXL-417: -- Summary: JexlArithmetic looses precision during arithmetic operator execution Key: JEXL-417 URL: https://issues.apache.org/jira/browse/JEXL-417 Project: Commons JEXL Issue Type: Bug Affects Versions: 3.3 Reporter: Henri Biestro Fix For: 3.3.1 When a an argument/variable is a BigDecimal or BigInteger, JEXL may try and convert it to double/long during arithmetic operator execution leading to unexpected results. (56.1B - 12) / 12 = 3.6 User intent about precision should be maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-411) Leading zeroes in floating point numbers should be optional
[ https://issues.apache.org/jira/browse/JEXL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789513#comment-17789513 ] Henri Biestro commented on JEXL-411: The logic for parsing is described in the [Parser.jjt|https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/parser/Parser.jjt] grammar, a [Javacc|https://javacc.github.io/javacc/tutorials/] grammar. I could not find an easy way to introduce the syntax you seek; controlling the production of float literals by adding states quickly became a tangled mess. May be you'll find a cleaner way. > Leading zeroes in floating point numbers should be optional > --- > > Key: JEXL-411 > URL: https://issues.apache.org/jira/browse/JEXL-411 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Felix Rudolphi >Priority: Minor > > When parsing arithmetic expressions, JEXL should be able to deal with omitted > leading zeroes in floating point numbers between -1.0 and 1.0, e.g. ".1" > "(1+0.1)*2" evaluates to 2.2, while "(1+.1)*2" gives a parsing error. In > Java, this is valid code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-411) Leading zeroes in floating point numbers should be optional
[ https://issues.apache.org/jira/browse/JEXL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789206#comment-17789206 ] Henri Biestro commented on JEXL-411: Tried to modify the grammar but this is not easy; JEXL allows 'x.3' as an (almost) equivalent for 'x[3]' , lexical states are probably required. If you've submit a PR, I'll gladly look at it. > Leading zeroes in floating point numbers should be optional > --- > > Key: JEXL-411 > URL: https://issues.apache.org/jira/browse/JEXL-411 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Felix Rudolphi >Priority: Minor > > When parsing arithmetic expressions, JEXL should be able to deal with omitted > leading zeroes in floating point numbers between -1.0 and 1.0, e.g. ".1" > "(1+0.1)*2" evaluates to 2.2, while "(1+.1)*2" gives a parsing error. In > Java, this is valid code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-416) Null-valued pragma throws NPE in 3.3
[
https://issues.apache.org/jira/browse/JEXL-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-416.
Resolution: Fixed
Thanks for catching this regression.
Commit
[0a2e943|https://github.com/apache/commons-jexl/commit/0a2e94323a642cc224b1b97ce28e87aaf073408e]
> Null-valued pragma throws NPE in 3.3
>
>
> Key: JEXL-416
> URL: https://issues.apache.org/jira/browse/JEXL-416
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: JEXL 3.3
> Java 21 (21+35) Red Hat, Inc.
> Linux 5.15.133.1-microsoft-standard-WSL2 (amd64)
>Reporter: William Price
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> Version 3.2.1 seemed to allow {{null}} as a value for pragmas, but version
> 3.3 throws NPE. I'm not necessarily advocating for null pragma values, but
> it's a behavior regression due to the use of {{{}TreeMap::merge{}}}. Even if
> disallowing nulls was desired, it should be a JexlException not NPE.
> Passes on 3.2.1:
> {code:java}
> var script = engine.createScript("#pragma myNull null\n");
> var pragmas = script.getPragmas();
> assertTrue(pragmas.containsKey("myNull"), "pragma key present?");
> assertNull(pragmas.get("myNull"), "expected null value"); {code}
> Behavior on 3.3:
> {code:java}
> assertThrows(
> NullPointerException.class,
> () -> engine.createScript("#pragma myNull null\n"));
> {code}
> {noformat}
> java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at java.base/java.util.TreeMap.merge(TreeMap.java:743)
> at
> org.apache.commons.jexl3.parser.JexlParser.declarePragma(JexlParser.java:557)
> at org.apache.commons.jexl3.parser.Parser.Pragma(Parser.java:1246)
> at org.apache.commons.jexl3.parser.Parser.JexlScript(Parser.java:63)
> at org.apache.commons.jexl3.parser.Parser.parse(Parser.java:25)
> at org.apache.commons.jexl3.internal.Engine.parse(Engine.java:1009)
> at
> org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:617)
> at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:69)
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:375)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-416) Null-valued pragma throws NPE in 3.3
[
https://issues.apache.org/jira/browse/JEXL-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-416:
---
Assignee: Henri Biestro
> Null-valued pragma throws NPE in 3.3
>
>
> Key: JEXL-416
> URL: https://issues.apache.org/jira/browse/JEXL-416
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: JEXL 3.3
> Java 21 (21+35) Red Hat, Inc.
> Linux 5.15.133.1-microsoft-standard-WSL2 (amd64)
>Reporter: William Price
>Assignee: Henri Biestro
>Priority: Major
>
> Version 3.2.1 seemed to allow {{null}} as a value for pragmas, but version
> 3.3 throws NPE. I'm not necessarily advocating for null pragma values, but
> it's a behavior regression due to the use of {{{}TreeMap::merge{}}}. Even if
> disallowing nulls was desired, it should be a JexlException not NPE.
> Passes on 3.2.1:
> {code:java}
> var script = engine.createScript("#pragma myNull null\n");
> var pragmas = script.getPragmas();
> assertTrue(pragmas.containsKey("myNull"), "pragma key present?");
> assertNull(pragmas.get("myNull"), "expected null value"); {code}
> Behavior on 3.3:
> {code:java}
> assertThrows(
> NullPointerException.class,
> () -> engine.createScript("#pragma myNull null\n"));
> {code}
> {noformat}
> java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at java.base/java.util.TreeMap.merge(TreeMap.java:743)
> at
> org.apache.commons.jexl3.parser.JexlParser.declarePragma(JexlParser.java:557)
> at org.apache.commons.jexl3.parser.Parser.Pragma(Parser.java:1246)
> at org.apache.commons.jexl3.parser.Parser.JexlScript(Parser.java:63)
> at org.apache.commons.jexl3.parser.Parser.parse(Parser.java:25)
> at org.apache.commons.jexl3.internal.Engine.parse(Engine.java:1009)
> at
> org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:617)
> at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:69)
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:375)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-416) Null-valued pragma throws NPE in 3.3
[
https://issues.apache.org/jira/browse/JEXL-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-416:
---
Fix Version/s: 3.3.1
> Null-valued pragma throws NPE in 3.3
>
>
> Key: JEXL-416
> URL: https://issues.apache.org/jira/browse/JEXL-416
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: JEXL 3.3
> Java 21 (21+35) Red Hat, Inc.
> Linux 5.15.133.1-microsoft-standard-WSL2 (amd64)
>Reporter: William Price
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3.1
>
>
> Version 3.2.1 seemed to allow {{null}} as a value for pragmas, but version
> 3.3 throws NPE. I'm not necessarily advocating for null pragma values, but
> it's a behavior regression due to the use of {{{}TreeMap::merge{}}}. Even if
> disallowing nulls was desired, it should be a JexlException not NPE.
> Passes on 3.2.1:
> {code:java}
> var script = engine.createScript("#pragma myNull null\n");
> var pragmas = script.getPragmas();
> assertTrue(pragmas.containsKey("myNull"), "pragma key present?");
> assertNull(pragmas.get("myNull"), "expected null value"); {code}
> Behavior on 3.3:
> {code:java}
> assertThrows(
> NullPointerException.class,
> () -> engine.createScript("#pragma myNull null\n"));
> {code}
> {noformat}
> java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at java.base/java.util.TreeMap.merge(TreeMap.java:743)
> at
> org.apache.commons.jexl3.parser.JexlParser.declarePragma(JexlParser.java:557)
> at org.apache.commons.jexl3.parser.Parser.Pragma(Parser.java:1246)
> at org.apache.commons.jexl3.parser.Parser.JexlScript(Parser.java:63)
> at org.apache.commons.jexl3.parser.Parser.parse(Parser.java:25)
> at org.apache.commons.jexl3.internal.Engine.parse(Engine.java:1009)
> at
> org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:617)
> at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:69)
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:375)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789193#comment-17789193 ] Henri Biestro commented on JEXL-414: I've added a rough performance evaluation test class and another JexlCache implementation to compare to. I played with some parameters to get a sense of it but I feel confident the cache handling only has a small impact on overall performance. Let me know what you find. Commit [b36890|https://github.com/apache/commons-jexl/commit/b36890794bcbef32acc6b11899e5848f10905609] > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-414) SoftCache may suffer from race conditions
[ https://issues.apache.org/jira/browse/JEXL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-414: --- Fix Version/s: 3.3.1 > SoftCache may suffer from race conditions > - > > Key: JEXL-414 > URL: https://issues.apache.org/jira/browse/JEXL-414 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Holger Sunke >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > I found the SoftCache used from within the JEXL class Engine to be very > relevant for overall performance (depending on the application) on the one > hand, but on the other hand it may suffer from race conditions. > While solid efford was taken to protect it from race conditions by > surrounding access using a ReadWriteLock, parallel read access actually do > reach out on a LinkedHashMap having set accessOrder=true. This means that on > every potentially parallel, non serialized invocation of LinkedHashMap#get > the order of elements is modified to bring the last accessed element down to > the tail of the internal linked list structure and modCount is incremented. > > In our application rendering web templates, we observe multiple of 1 > access on the SoftCache per page impression and multiple of 10 page > impressions per second per JVM instance. > Not sure whether this is result of race condition claimed above, in heapdumps > of that application I observed the LinkedHashMap used within SoftCache having > a size of ~9500 elements while the SoftCache#size is set to limit the cache > to 5000 elements. Additionaly the LinkedHashMap#modCount shows up with > arbitrary giant positive or negative numbers, telling me it has overflown > already after some hours of application uptime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
