[jira] [Commented] (JEXL-392) Enable namespace declaration based on scripts
[ https://issues.apache.org/jira/browse/JEXL-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698021#comment-17698021 ] Dmitri Blinov commented on JEXL-392: If I'm allowed to express an opinion, this feature complicates the context/pragma design to support edge use case. It would be more practical imho to refactor the code the way pragma processing could be shifted from interpreter to custom (subclassed) context implementation, where the desired enhancement could be implemented without rewriting interpreter every time. > Enable namespace declaration based on scripts > -- > > Key: JEXL-392 > URL: https://issues.apache.org/jira/browse/JEXL-392 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > It is often convenient to reuse pieces of code in multiple places. This is > easy to do with namespaces and Java classes (or objects) but impossible > through scripts. The workaround Is to use maps that contain the various > functions and use an object but it requires re-evaluating the script each > time this is needed which is costly. > Ideally, there should be a way to declare a namespace whose bound object > would be the result of the evaluation of JEXL code. > HOW: > By adding a new pragma imaginatively called 'module' behaving as namespace > declaration but whose value must be an expression (as a string) that will be > evaluated during pragma processing. > One important usage warning here is the idem-potence of the expression whose > result should be stable to avoid any bizarre behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-390) Pragmas should not be statements
[
https://issues.apache.org/jira/browse/JEXL-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651323#comment-17651323
]
Dmitri Blinov commented on JEXL-390:
I understand your point to keep the things as much backward compatible as
possible but if pragmas are allowed to be placed closer to the the point where
they are used, they stiil can unintentionally influence the interpretation of
the code before them, because they are still pragmas and not lexical
preprocessor directives, like in CPP. Here is artificial example.
{code}
@Test
public void testPragmaOptions1() {
final String str = "i; #pragma jexl.options '-strict'\n";
final JexlEngine jexl = new JexlBuilder().strict(true).create();
final JexlScript e = jexl.createScript(str);
final JexlContext ctxt = new MapContext();
try {
final Object o = e.execute(ctxt);
Assert.fail("i should not be resolved");
} catch (final JexlException xany) {
Assert.assertNotNull(xany);
}
}
{code}
> Pragmas should not be statements
>
>
> Key: JEXL-390
> URL: https://issues.apache.org/jira/browse/JEXL-390
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.3
>
>
> In Jexl pragmas are treated as statements syntactically, but do not find
> their way to AST tree and this leads to strange bugs like in the following
> example
> {code}
> @Test
> public void testBadPragmas() throws Exception {
> final JexlEngine jexl = new
> JexlBuilder().cache(1024).debug(true).create();
> final JexlScript script = jexl.createScript("if (true) #pragma one
> 42");
> JexlContext jc = new MapContext();
> final Object result = script.execute(jc);
> debuggerCheck(jexl);
> }
> {code}
> While this partucular bug can be trivially fixed, in fact the whole idea to
> allow putting pragmas for example inside a loop or inside if-branch is a
> strange language design (I'm not aware of examples in other languages) as it
> gives false idea of the pragma being controlled by script execution logic.
> If there's no reason or use case to keep this design as is, my proposal is to
> make a grammar change and allow pragmas to be declared only at the top of the
> script. Another point to change current pragma implementation is that pragmas
> can not be used with expressions, e.g. no way to specify standard options /
> imports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-390) Pragmas should not be statements
[
https://issues.apache.org/jira/browse/JEXL-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-390:
---
Description:
In Jexl pragmas are treated as statements syntactically, but do not find their
way to AST tree and this leads to strange bugs like in the following example
{code}
@Test
public void testBadPragmas() throws Exception {
final JexlEngine jexl = new
JexlBuilder().cache(1024).debug(true).create();
final JexlScript script = jexl.createScript("if (true) #pragma one 42");
JexlContext jc = new MapContext();
final Object result = script.execute(jc);
debuggerCheck(jexl);
}
{code}
While this partucular bug can be trivially fixed, in fact the whole idea to
allow putting pragmas for example inside a loop or inside if-branch is a
strange language design (I'm not aware of examples in other languages) as it
gives false idea of the pragma being controlled by script execution logic.
If there's no reason or use case to keep this design as is, my proposal is to
make a grammar change and allow pragmas to be declared only at the top of the
script. Another point to change current pragma implementation is that pragmas
can not be used with expressions, e.g. no way to specify standard options /
imports.
was:
In Jexl pragmas are treated as statements syntactically, but do not find their
way to AST tree and this leads to strange bugs like in the following example
{code}
@Test
public void testBadPragmas() throws Exception {
final JexlEngine jexl = new
JexlBuilder().cache(1024).debug(true).create();
final JexlScript script = jexl.createScript("if (true) #pragma one 42");
JexlContext jc = new MapContext();
final Object result = script.execute(jc);
debuggerCheck(jexl);
}
{code}
While this partucular bug can be trivially fixed, in fact the whole idea to
allow putting pragmas inside a loop or inside if-branch is a strange language
design (I'm not aware of examples in other languages) as it gives false idea of
the pragma being controlled by script execution logic.
If there's no reason or use case to keep this design as is, my proposal is to
make a grammar change and allow pragmas to be declared only at the top of the
script
> Pragmas should not be statements
>
>
> Key: JEXL-390
> URL: https://issues.apache.org/jira/browse/JEXL-390
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Dmitri Blinov
>Priority: Minor
>
> In Jexl pragmas are treated as statements syntactically, but do not find
> their way to AST tree and this leads to strange bugs like in the following
> example
> {code}
> @Test
> public void testBadPragmas() throws Exception {
> final JexlEngine jexl = new
> JexlBuilder().cache(1024).debug(true).create();
> final JexlScript script = jexl.createScript("if (true) #pragma one
> 42");
> JexlContext jc = new MapContext();
> final Object result = script.execute(jc);
> debuggerCheck(jexl);
> }
> {code}
> While this partucular bug can be trivially fixed, in fact the whole idea to
> allow putting pragmas for example inside a loop or inside if-branch is a
> strange language design (I'm not aware of examples in other languages) as it
> gives false idea of the pragma being controlled by script execution logic.
> If there's no reason or use case to keep this design as is, my proposal is to
> make a grammar change and allow pragmas to be declared only at the top of the
> script. Another point to change current pragma implementation is that pragmas
> can not be used with expressions, e.g. no way to specify standard options /
> imports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-390) Pragmas should not be statements
Dmitri Blinov created JEXL-390:
--
Summary: Pragmas should not be statements
Key: JEXL-390
URL: https://issues.apache.org/jira/browse/JEXL-390
Project: Commons JEXL
Issue Type: Improvement
Reporter: Dmitri Blinov
In Jexl pragmas are treated as statements syntactically, but do not find their
way to AST tree and this leads to strange bugs like in the following example
{code}
@Test
public void testBadPragmas() throws Exception {
final JexlEngine jexl = new
JexlBuilder().cache(1024).debug(true).create();
final JexlScript script = jexl.createScript("if (true) #pragma one 42");
JexlContext jc = new MapContext();
final Object result = script.execute(jc);
debuggerCheck(jexl);
}
{code}
While this partucular bug can be trivially fixed, in fact the whole idea to
allow putting pragmas inside a loop or inside if-branch is a strange language
design (I'm not aware of examples in other languages) as it gives false idea of
the pragma being controlled by script execution logic.
If there's no reason or use case to keep this design as is, my proposal is to
make a grammar change and allow pragmas to be declared only at the top of the
script
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-389) Improve parsing timings
[ https://issues.apache.org/jira/browse/JEXL-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643956#comment-17643956 ] Dmitri Blinov commented on JEXL-389: Thank you very much for your promt fix. With modern hardware having many cores, and more to come, the problem is not that odd, IMO. I've bumped into this issue in a real life project where jexl2 is still used. Since the flaw remained unnoticed in current JEXL version, I decided may be it's worth reporting on it. > Improve parsing timings > --- > > Key: JEXL-389 > URL: https://issues.apache.org/jira/browse/JEXL-389 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.3 > > > There seems to be a known and old issue with javacc with respect to creation > of LookaheadSuccess exception instance inside parser class, which hits the > performance if parsing is intensively used and many Parser objects are > created. > More details and suggested fixing approach can be looked at > https://issues.apache.org/jira/browse/SOLR-11242 > I think we can adopt the fix until it will be fixed in javacc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-389) Improve parsing timings
Dmitri Blinov created JEXL-389: -- Summary: Improve parsing timings Key: JEXL-389 URL: https://issues.apache.org/jira/browse/JEXL-389 Project: Commons JEXL Issue Type: Improvement Reporter: Dmitri Blinov There seems to be a known and old issue with javacc with respect to creation of LookaheadSuccess exception instance inside parser class, which hits the performance if parsing is intensively used and many Parser objects are created. More details and suggested fixing approach can be looked at https://issues.apache.org/jira/browse/SOLR-11242 I think we can adopt the fix until it will be fixed in javacc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-385) Support disabling fortran-style relational operators syntax
[ https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636192#comment-17636192 ] Dmitri Blinov commented on JEXL-385: Thank you! Maybe it should be mentioned in docs > Support disabling fortran-style relational operators syntax > > > Key: JEXL-385 > URL: https://issues.apache.org/jira/browse/JEXL-385 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, > treat as plain identifiers > https://github.com/apache/commons-jexl/pull/139 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-385) Support disabling fortran-style relational operators syntax
[ https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631152#comment-17631152 ] Dmitri Blinov edited comment on JEXL-385 at 11/9/22 4:55 PM: - [~henrib] Do you mean we can now come back to the idea of reintroducing ‘in’ as an alias to match operator ? Afaik ‘in’ keyword was dropped from syntax years ago. was (Author: dmitri_blinov): [~henrib] Do you mean we can now reintroduce ‘in’ as an alias to match operator ? Afaik ‘in’ keyword was dropped from syntax years ago. > Support disabling fortran-style relational operators syntax > > > Key: JEXL-385 > URL: https://issues.apache.org/jira/browse/JEXL-385 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, > treat as plain identifiers > https://github.com/apache/commons-jexl/pull/139 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-385) Support disabling fortran-style relational operators syntax
[ https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631152#comment-17631152 ] Dmitri Blinov commented on JEXL-385: [~henrib] Do you mean we can now reintroduce ‘in’ as an alias to match operator ? Afaik ‘in’ keyword was dropped from syntax years ago. > Support disabling fortran-style relational operators syntax > > > Key: JEXL-385 > URL: https://issues.apache.org/jira/browse/JEXL-385 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, > treat as plain identifiers > https://github.com/apache/commons-jexl/pull/139 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-385) Support disabling fortran-style relational operators syntax
Dmitri Blinov created JEXL-385: -- Summary: Support disabling fortran-style relational operators syntax Key: JEXL-385 URL: https://issues.apache.org/jira/browse/JEXL-385 Project: Commons JEXL Issue Type: Improvement Reporter: Dmitri Blinov Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, treat as plain identifiers https://github.com/apache/commons-jexl/pull/139 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629376#comment-17629376 ] Dmitri Blinov commented on JEXL-381: You're right - ClassLoader.loadClass() does not trigger class initialization, I've confused it with Class.forName() > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629358#comment-17629358 ] Dmitri Blinov commented on JEXL-381: This can be a little bit tricky. Current Permissions checks are performed on *already* loaded classes to access class annotations etc. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629303#comment-17629303 ] Dmitri Blinov commented on JEXL-381: Now that I've reviewed the code, I think one of the things that should be added from security point is permission checks to classloads via pragma namespace declarations. Though there is no way to call methods from classes outside permissions scope, there might be undesirable side effects from class loading itself - static code initialization, native library code loading etc. Maybe there should be an option to disable namespace declarations via pragmas at all for those who want to absolutely limit what may be accessed from inside the box. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (JEXL-382) Simplify grammar and lexical state management
[ https://issues.apache.org/jira/browse/JEXL-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov reopened JEXL-382: Last minute amendments https://github.com/apache/commons-jexl/pull/135 > Simplify grammar and lexical state management > - > > Key: JEXL-382 > URL: https://issues.apache.org/jira/browse/JEXL-382 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > Here is the proposal to tidy up grammar and lexical state management rules. > The jar size reduction is also a small bonus to code cleanup > https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[
https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627881#comment-17627881
]
Dmitri Blinov commented on JEXL-381:
[~henrib] The sandbox is not part of Jexl, rather part of some project that
incorporates Jexl, since there are some project specific pecularities. As I
personally prefer subclassing to delegation, it comprises primaraly of
extensions to Permissions and Uberspect. I don't think it will be of much use
to others as is, but since you're asking I can publish it with some omissions.
The Uberspect deals with some magic around j.n.URI class to override toURL()
method for file schemes. The permissions extension is as follows
{code:java}
public class MyPermissions extends Permissions {
protected static final Set restrictedConstructors =
Collections.unmodifiableSet(new LinkedHashSet(Arrays.asList(
"java.io.File", "java.io.FileDescriptor", "java.io.FileInputStream",
"java.io.FileOutputStream",
"java.io.FilePermission", "java.io.FileReader", "java.io.FileWriter",
"java.io.PrintStream", "java.io.PrintWriter",
"java.io.RandomAccessFile", "java.io.ObjectInputStream",
"java.util.zip.ZipFile", "java.util.jar.JarFile",
"java.net.URL", "java.net.URLClassLoader"
)));
protected boolean isAllowedMethod(Method m) {
if (!Modifier.isPublic(m.getModifiers()))
return false;
if (m.isSynthetic())
return false;
Class clazz = m.getDeclaringClass();
String method = m.getName();
// Prevent direct invocation
if (Class.class.isAssignableFrom(clazz) && ("forName".equals(method) ||
"getClassLoader".equals(method)))
return false;
// Prevent direct invocation
if (Method.class.isAssignableFrom(clazz) && ("invoke".equals(method) ||
"setAccessible".equals(method)))
return false;
// Prevent direct invocation
if (MethodHandle.class.isAssignableFrom(clazz) &&
("invoke".equals(method) || "invokeExact".equals(method)))
return false;
// Prevent direct invocation
if (Constructor.class.isAssignableFrom(clazz) &&
"newInstance".equals(method))
return false;
// Prevent direct invocation
if (File.class.isAssignableFrom(clazz) &&
("createTempFile".equals(method) || "listRoots".equals(method)))
return false;
// Prevent direct invocation
if (URL.class.isAssignableFrom(clazz) &&
"setURLStreamHandlerFactory".equals(method))
return false;
// Prevent direct invocation
if (URLConnection.class.isAssignableFrom(clazz) &&
("setContentHandlerFactory".equals(method) ||
"setDefaultAllowUserInteraction".equals(method) ||
"setDefaultRequestProperty".equals(method) ||
"setFileNameMap".equals(method)))
return false;
// Prevent static method invocations on restricted classes
String name = clazz.getName();
if (MyDefaultContext.PackageResolver.restrictedNames.contains(name) &&
Modifier.isStatic(m.getModifiers()))
return false;
MyPermission msyc = clazz.getAnnotation(MyPermission.class);
MyScripting permission = (msyc != null) ? msyc.scripting() :
MyScripting.ALLOW;
MyPermission msyp = m.getAnnotation(MyPermission.class);
if (msyp != null)
permission = msyp.scripting();
if (permission == MyScripting.RESTRICT)
return false;
return true;
}
/**
* Checks whether a method disallows introspection.
* Since methods can be overridden, this also checks that no superclass
or interface
* explictly disallows this methods.
* @param method the method to check
* @return true if JEXL is allowed to introspect, false otherwise
*/
@Override
public boolean allow(Method method) {
if (method == null)
return false;
if (!isAllowedMethod(method))
return false;
return super.allow(method);
}
/**
* Checks whether a constructor disallows introspection.
* @param ctor the constructor to check
* @return true if JEXL is allowed to introspect, false otherwise
*/
@Override
public boolean allow(Constructor ctor) {
if (ctor == null)
return false;
if (!Modifier.isPublic(ctor.getModifiers()))
return false;
Class clazz = ctor.getDeclaringClass();
if (!allow(clazz))
return false;
String name = clazz.getName();
if (restrictedConstructors.contains(name))
return false;
if (MyDefaultContext.PackageResolver.restrictedNames.contains(name))
return false;
return true;
}
}{code}
> Change default JEXL configuration to a more security-friendly behaviour
>
>
> Key: JEXL-381
>
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626766#comment-17626766 ] Dmitri Blinov edited comment on JEXL-381 at 10/31/22 7:07 PM: -- [~henrib] I don't remember exact reason why I didn't opt for the new way of defining restrictions. May be its because I wanted to exclude NoJexl annotation checks to save some cycles and there was no way to override the default behavior for a private method ) was (Author: dmitri_blinov): [~henrib] I don't remember exact reason why I didn't opted for the new way of defining restrictions. May be its because I wanted to exclude NoJexl annotation checks to save some cycles and there was no way to override the default behavior for a private method ) > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626766#comment-17626766 ] Dmitri Blinov commented on JEXL-381: [~henrib] I don't remember exact reason why I didn't opted for the new way of defining restrictions. May be its because I wanted to exclude NoJexl annotation checks to save some cycles and there was no way to override the default behavior for a private method ) > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[
https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626731#comment-17626731
]
Dmitri Blinov commented on JEXL-381:
IMO the idea to sandbox JEXL by default is not without good sense, since there
might be people around who are not experienced in security problems. Jexl may
provide them with some basics.
My experience in sandboxing JEXL, so that it would be difficult to use it as a
security hole, is that you need to hinder many access paths, not only disabling
access to certain packages, but preventing access to object classloader for
example, since there is possibility to obtain the restricted object by calling
ClassLoader.findClass() or Class.forName("") and bypass standard constructor
package checks. Other obvious measures are restricting access to
java.lang.System static methods, like System.exit(code). My currentl list for
completely restricted class methods is
"java.lang.System", "java.lang.Compiler", "java.lang.Process",
"java.lang.ProcessBuilder", "java.lang.Runtime",
"java.lang.RuntimePermission", "java.lang.SecurityManager", "java.lang.Thread",
"java.lang.ThreadGroup",
"java.lang.ClassLoader", "java.net.URLClassLoader", "java.io.FileDescriptor"
Here is my list to restricted constructors - IMO its ok to work with objects if
you get them somehow, via secured api, but you should not be able to create
those objects in uncontrolled manner
"java.io.File", "java.io.FileDescriptor", "java.io.FileInputStream",
"java.io.FileOutputStream",
"java.io.FilePermission", "java.io.FileReader", "java.io.FileWriter",
"java.io.PrintStream", "java.io.PrintWriter",
"java.io.RandomAccessFile", "java.io.ObjectInputStream",
"java.util.zip.ZipFile", "java.util.jar.JarFile",
"java.net.URL", "java.net.URLClassLoader"
Other resticted methods are
{code:java}
// Prevent direct invocation
if (Class.class.isAssignableFrom(clazz) && ("forName".equals(method) ||
"getClassLoader".equals(method)))
return false;
// Prevent direct invocation
if (Method.class.isAssignableFrom(clazz) && ("invoke".equals(method) ||
"setAccessible".equals(method)))
return false;
// Prevent direct invocation
if (MethodHandle.class.isAssignableFrom(clazz) &&
("invoke".equals(method) || "invokeExact".equals(method)))
return false;
// Prevent direct invocation
if (Constructor.class.isAssignableFrom(clazz) &&
"newInstance".equals(method))
return false;
// Prevent direct invocation
if (File.class.isAssignableFrom(clazz) &&
("createTempFile".equals(method) || "listRoots".equals(method)))
return false;
// Prevent direct invocation
if (URL.class.isAssignableFrom(clazz) &&
"setURLStreamHandlerFactory".equals(method))
return false;
{code}
So, there is alot to think about...
> Change default JEXL configuration to a more security-friendly behaviour
>
>
> Key: JEXL-381
> URL: https://issues.apache.org/jira/browse/JEXL-381
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> JEXL's default builder allows accessing and calling any public method, field
> or constructor of any public class. This might not be desirable since a quick
> exploration of JEXL will quickly conclude the library allows arbitrary
> execution through commands (ProcessBuilder) or getting to the file-system
> through URL or File. This improvement goal is to change JEXL's permeability
> as an explicit option and user decision, not a default behaviour.
> HOW:
> By changing the current JexlBuilder to use a restricted set of permissions
> whilst instantiating the Uberspect, we can ensure a minimal useful set of
> classes can be accessed and only those by default. By removing access to
> almost all classes that interact with the JVM host and file-system, we ensure
> a default isolation that would significantly reduce the ability to use JEXL
> as an attack vector.
> CAVEAT:
> This change will likely break many scripts that were dependant upon the
> default permeability.
> [~ggregory], [~dmitri_blinov] your opinions are welcome :-)
> https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-382) Simplify grammar and lexical state management
[ https://issues.apache.org/jira/browse/JEXL-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov updated JEXL-382: --- Description: Here is the proposal to tidy up grammar and lexical state management rules. The jar size reduction is also a small bonus to code cleanup https://github.com/apache/commons-jexl/pull/134 was: Here is the proposal to tidy up grammar and lexical state management rules. https://github.com/apache/commons-jexl/pull/134 > Simplify grammar and lexical state management > - > > Key: JEXL-382 > URL: https://issues.apache.org/jira/browse/JEXL-382 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Dmitri Blinov >Priority: Major > > Here is the proposal to tidy up grammar and lexical state management rules. > The jar size reduction is also a small bonus to code cleanup > https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-382) Simplify grammar and lexical state management
[ https://issues.apache.org/jira/browse/JEXL-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov updated JEXL-382: --- Description: Here is the proposal to tidy up grammar and lexical state management rules. https://github.com/apache/commons-jexl/pull/134 was:https://github.com/apache/commons-jexl/pull/134 > Simplify grammar and lexical state management > - > > Key: JEXL-382 > URL: https://issues.apache.org/jira/browse/JEXL-382 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Dmitri Blinov >Priority: Major > > Here is the proposal to tidy up grammar and lexical state management rules. > https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-382) Simplify grammar and lexical state management
Dmitri Blinov created JEXL-382: -- Summary: Simplify grammar and lexical state management Key: JEXL-382 URL: https://issues.apache.org/jira/browse/JEXL-382 Project: Commons JEXL Issue Type: Improvement Reporter: Dmitri Blinov https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558174#comment-17558174
]
Dmitri Blinov edited comment on JEXL-372 at 6/23/22 5:27 PM:
-
The following test case fails
{code:java}
@Test public void testForLoop00() {
String src = "(l)->{ for(let x = 0, y = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
}
{code}
While the following test case passes successfully
{code:java}
@Test public void testForLoop0() {
String src = "(l)->{ for(let x = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
} {code}
was (Author: dmitri_blinov):
The following test case fails
{code:java}
@Test public void testForLoop00() {
String src = "(l)->{ for(let x = 0, y = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
}
{code}
While following test case passes successfully
{code:java}
@Test public void testForLoop0() {
String src = "(l)->{ for(let x = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
} {code}
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558174#comment-17558174
]
Dmitri Blinov commented on JEXL-372:
The following test case fails
{code:java}
@Test public void testForLoop00() {
String src = "(l)->{ for(let x = 0, y = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
}
{code}
While following test case passes successfully
{code:java}
@Test public void testForLoop0() {
String src = "(l)->{ for(let x = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
} {code}
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-373) Add support for prefix/postfix increment/decrement operators
[
https://issues.apache.org/jira/browse/JEXL-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553286#comment-17553286
]
Dmitri Blinov edited comment on JEXL-373 at 6/12/22 5:05 PM:
-
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded {{+=}} / {{-=}} operators, in case those
are defined for the incremented/decremented target object. One might expect
that ++x should be equal to x += 1 rather than x = x + 1 like in current
implementation. From a point it can be a better choice in case of complex
structeres (like collections or atomics), because casual + operator in that
case may mean creation of a *new* object with right argument then applied to
it, whereas self-add += operator may mean modification of the *existing*
left-side object with right argument. Suppose we have AtomicLong and selfAdd
operator mapped to {{{}AtomicLong.addAndGet(delta){}}}, and add operator which
casts {{AtomicLong}} to Long for evaluation. Then the introduction of the ++
operator would follow the rule of the least surprise, as it will correctly
increment base value.
was (Author: dmitri_blinov):
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded {{+=}} / {{-=}} operators, in case those
are defined for the incremented/decremented target object. One might expect
that ++x should be equal to x += 1 rather than x = x + 1 like in current
implementation. I think this can be a better choice in case of complex
structeres (like collections or atomics) too, because casual + operator in that
case may mean creation of a *new* object adjusted with one element, whereas
self-add += operator may mean modification of the *existing* left-side object.
> Add support for prefix/postfix increment/decrement operators
>
>
> Key: JEXL-373
> URL: https://issues.apache.org/jira/browse/JEXL-373
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> The prefix/postfix increment/decrement operators as in:
> {code}lhs++; ++lhs; lhs--; --lhs;{code}
> lhs being a left-hand-side value, a value that can be assigned.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-373) Add support for prefix/postfix increment/decrement operators
[
https://issues.apache.org/jira/browse/JEXL-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553286#comment-17553286
]
Dmitri Blinov edited comment on JEXL-373 at 6/12/22 4:53 PM:
-
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded {{+=}} / {{-=}} operators, in case those
are defined for the incremented/decremented target object. One might expect
that ++x should be equal to x += 1 rather than x = x + 1 like in current
implementation. I think this can be a better choice in case of complex
structeres (like collections or atomics) too, because casual + operator in that
case may mean creation of a *new* object adjusted with one element, whereas
self-add += operator may mean modification of the *existing* left-side object.
was (Author: dmitri_blinov):
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded {{+=}} / {{-=}} operators, in case those
are defined for the incremented/decremented target object. One might expect
that ++x should be equal to x += 1
> Add support for prefix/postfix increment/decrement operators
>
>
> Key: JEXL-373
> URL: https://issues.apache.org/jira/browse/JEXL-373
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> The prefix/postfix increment/decrement operators as in:
> {code}lhs++; ++lhs; lhs--; --lhs;{code}
> lhs being a left-hand-side value, a value that can be assigned.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (JEXL-372) Add support for 'standard' for loop
[ https://issues.apache.org/jira/browse/JEXL-372 ]
Dmitri Blinov deleted comment on JEXL-372:
was (Author: dmitri_blinov):
Once you mentioned complexity of overload checks for self\{Add,Subtract,..} I
recalled that when I tackeled that problem myself, I added the default
implementations for those methods to base JexlArithmetic
{code:java}
public Object selfAdd(Object left, Object right) {
return add(left, right);
}
{code}
and adjusted Operators to call them directly if there were no overloads
detected.
{code}
switch (operator) {
case SELF_ADD:
return arithmetic.selfAdd(arg1, arg2);
{code}
It shaves off some cycles on preventing always using reflection
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-373) Add support for prefix/postfix increment/decrement operators
[
https://issues.apache.org/jira/browse/JEXL-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553287#comment-17553287
]
Dmitri Blinov commented on JEXL-373:
Once you mentioned complexity of overload checks for self\{Add,Subtract,..} I
recalled that when I tackeled that problem myself, I added the default
implementations for those methods to base JexlArithmetic
{code:java}
public Object selfAdd(Object left, Object right) {
return add(left, right);
}
{code}
and adjusted Operators to call them directly if there were no overloads
detected.
{code}
switch (operator) {
case SELF_ADD:
return arithmetic.selfAdd(arg1, arg2);
{code}
It shaves off some cycles on preventing always using reflection
> Add support for prefix/postfix increment/decrement operators
>
>
> Key: JEXL-373
> URL: https://issues.apache.org/jira/browse/JEXL-373
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> The prefix/postfix increment/decrement operators as in:
> {code}lhs++; ++lhs; lhs--; --lhs;{code}
> lhs being a left-hand-side value, a value that can be assigned.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (JEXL-372) Add support for 'standard' for loop
[ https://issues.apache.org/jira/browse/JEXL-372 ]
Dmitri Blinov deleted comment on JEXL-372:
was (Author: dmitri_blinov):
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded {{\+=}} / {{\-=}} operators, in case
those are defined for the incremented/decremented target object. One might
expect that ++x should be equal to x += 1
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-373) Add support for prefix/postfix increment/decrement operators
[
https://issues.apache.org/jira/browse/JEXL-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553286#comment-17553286
]
Dmitri Blinov commented on JEXL-373:
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded {{+=}} / {{-=}} operators, in case those
are defined for the incremented/decremented target object. One might expect
that ++x should be equal to x += 1
> Add support for prefix/postfix increment/decrement operators
>
>
> Key: JEXL-373
> URL: https://issues.apache.org/jira/browse/JEXL-373
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> The prefix/postfix increment/decrement operators as in:
> {code}lhs++; ++lhs; lhs--; --lhs;{code}
> lhs being a left-hand-side value, a value that can be assigned.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (JEXL-372) Add support for 'standard' for loop
[ https://issues.apache.org/jira/browse/JEXL-372 ]
Dmitri Blinov deleted comment on JEXL-372:
was (Author: dmitri_blinov):
The following use case returns 1 in JS
{code:java}
@Test
public void testIncrementOperatorOnNull() throws Exception {
final JexlEngine jexl = new JexlBuilder().strict(false).create();
JexlScript script;
Object result; script = jexl.createScript("var i = null; ++i");
result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
May be we should follow suit?
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553283#comment-17553283
]
Dmitri Blinov commented on JEXL-372:
Once you mentioned complexity of overload checks for self\{Add,Subtract,..} I
recalled that when I tackeled that problem myself, I added the default
implementations for those methods to base JexlArithmetic
{code:java}
public Object selfAdd(Object left, Object right) {
return add(left, right);
}
{code}
and adjusted Operators to call them directly if there were no overloads
detected.
{code}
switch (operator) {
case SELF_ADD:
return arithmetic.selfAdd(arg1, arg2);
{code}
It shaves off some cycles on preventing always using reflection
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553276#comment-17553276
]
Dmitri Blinov edited comment on JEXL-372 at 6/12/22 2:55 PM:
-
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded {{\+=}} / {{\-=}} operators, in case
those are defined for the incremented/decremented target object. One might
expect that ++x should be equal to x += 1
was (Author: dmitri_blinov):
There is also an open question whether default increment/decrement operator
arithmetic should trigger overloaded += / -+ operators, in case those are
defined for the incremented/decremented target object. One might expect that
++x should be equal to x += 1
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-372) Add support for 'standard' for loop
[ https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553276#comment-17553276 ] Dmitri Blinov commented on JEXL-372: There is also an open question whether default increment/decrement operator arithmetic should trigger overloaded += / -+ operators, in case those are defined for the incremented/decremented target object. One might expect that ++x should be equal to x += 1 > Add support for 'standard' for loop > --- > > Key: JEXL-372 > URL: https://issues.apache.org/jira/browse/JEXL-372 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > It would be nice to allow the C/Javascript/Java for loop: > for(init-expression; predicate-expression; step-expression) body > This calls for the prefix/postfix increment/decrement operators. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553261#comment-17553261
]
Dmitri Blinov edited comment on JEXL-372 at 6/12/22 2:22 PM:
-
The following use case returns 1 in JS
{code:java}
@Test
public void testIncrementOperatorOnNull() throws Exception {
final JexlEngine jexl = new JexlBuilder().strict(false).create();
JexlScript script;
Object result; script = jexl.createScript("var i = null; ++i");
result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
May be we should follow suit?
was (Author: dmitri_blinov):
The following test case returns 1 in JS
{code:java}
@Test
public void testIncrementOperatorOnNull() throws Exception {
final JexlEngine jexl = new JexlBuilder().strict(false).create();
JexlScript script;
Object result; script = jexl.createScript("var i = null; ++i");
result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
May be we should follow suit?
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553261#comment-17553261
]
Dmitri Blinov commented on JEXL-372:
The following test case returns 1 in JS
{code:java}
@Test
public void testIncrementOperatorOnNull() throws Exception {
final JexlEngine jexl = new JexlBuilder().strict(false).create();
JexlScript script;
Object result; script = jexl.createScript("var i = null; ++i");
result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
May be we should follow suit?
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539003#comment-17539003 ] Dmitri Blinov commented on JEXL-369: [~henrib] Great job, thanks! > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-367) Named function and fat-arrow (=>) lambda syntax
[
https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539002#comment-17539002
]
Dmitri Blinov commented on JEXL-367:
There are a couple of notes on current named function implementation, if you
don't mind...
It seems Jexl treats named functions like expressions, not statments. This
allows a little weird syntax like
{code:java}
@Test
public void testNamedFuncIsExpr() {
String src = "var i = function foo(x) { x + x }; i(6)";
JexlEngine jexl = createEngine();
JexlScript script = jexl.createScript(src);
Object result = script.execute(null);
Assert.assertEquals(12, result);
}
{code}
Also, since declaring a named function means to implicitly declare a variable,
then logically, local variable declaration feature should be checked, to see if
we are allowed to do so in our context, for example if we are evaluating a
simple expression.
Moreover, since we are declaring a lexical variable with named function, then I
think, in analogy with `var` we should restrict conditional single-statement
declarations to avoid strange errors like in example
{code:java}
@Test
public void testNamedFuncConditional() {
String src = "if (false) function foo(x) { x + x }; var foo = 1";
JexlEngine jexl = createEngine();
JexlScript script = jexl.createScript(src);
Object result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
> Named function and fat-arrow (=>) lambda syntax
> ---
>
> Key: JEXL-367
> URL: https://issues.apache.org/jira/browse/JEXL-367
> Project: Commons JEXL
> Issue Type: Wish
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Assignee: Henri Biestro
>Priority: Major
>
> The JEXL code surprisingly looks a lot like Javascript. I think this change
> is a good transition for folks to update the code, and it's pretty fine if
> they can tolerate using the deprecate syntax and don't mind seeing a warning
> log pop up every time.
> I'd like to propose supporting => and deprecate ->.
> The reasons are
> - JavaScript becomes very popular and many people are familiar with it.
> - JEXL is more like for a quick short script. In many scenarios, the target
> audiences are not a programer. They often mistake a language as a JavaScript
> (from my experience).
> - JEXL syntax already looks a lot like JavaScript
> -- var for variable declaration (Java added in Java 10, but JavaScript
> supports this from the beginning)
> -- The function keyword
> -- Implicit type coercion
> -- Ternary operator
> The proposed change.
> * Support => in addition to ->
> * Deprecate -> and show a warning log when it's used.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17538323#comment-17538323
]
Dmitri Blinov edited comment on JEXL-369 at 5/17/22 4:42 PM:
-
I respectfully disagree :)
Loop assignment to constant fails in Java but passes in Jexl.
{code:java}
@Test
public void testConst4() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
try {
final JexlScript script = jexl.createScript( "const x; for (var i :
[1,2,3]) x = i");
Assert.fail("should fail, x is a constant");
} catch(JexlException.Parsing xparse) {
Assert.assertTrue(xparse.getMessage().contains("x"));
}
}
{code}
And vise versa, like this is a valid initialization in Java but fails in Jexl
{code:java}
@Test
public void testConst5() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
final JexlScript script = jexl.createScript( "const x; if (true) x = 1;
else x = 2");
Object result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
was (Author: dmitri_blinov):
I respectfully disagree :)
Loop assignment to constant fails in Java but passes in Jexl.
{code:java}
@Test
public void testConst4() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
try {
final JexlScript script = jexl.createScript( "const x; for (var i :
[1,2,3]) x = i");
Assert.fail("should fail, x is a constant");
} catch(JexlException.Parsing xparse) {
Assert.assertTrue(xparse.getMessage().contains("x"));
}
}
{code}
And otherwise, like this is a valid initialization in Java but fails in Jexl
{code:java}
@Test
public void testConst5() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
final JexlScript script = jexl.createScript( "const x; if (true) x = 1;
else x = 2");
Object result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17538323#comment-17538323
]
Dmitri Blinov commented on JEXL-369:
I respectfully disagree :)
Loop assignment to constant fails in Java but passes in Jexl.
{code:java}
@Test
public void testConst4() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
try {
final JexlScript script = jexl.createScript( "const x; for (var i :
[1,2,3]) x = i");
Assert.fail("should fail, x is a constant");
} catch(JexlException.Parsing xparse) {
Assert.assertTrue(xparse.getMessage().contains("x"));
}
}
{code}
And otherwise, like this is a valid initialization in Java but fails in Jexl
{code:java}
@Test
public void testConst5() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
final JexlScript script = jexl.createScript( "const x; if (true) x = 1;
else x = 2");
Object result = script.execute(null);
Assert.assertEquals(1, result);
}
{code}
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537961#comment-17537961 ] Dmitri Blinov commented on JEXL-369: Oh, that one is tricky, need to track loops and branches. Complicates things considerably, with little to none usage. Can't recall the case when it was really needed in java. May be we should stick to KIS > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537687#comment-17537687
]
Dmitri Blinov edited comment on JEXL-369 at 5/16/22 5:39 PM:
-
[~henrib] I'm terribly sorry but can not grasp your idea with current const
declarations. We are allowing the constant to be declared but blocking its any
further usage and initialization.
{code:java}
@Test
public void testConst2() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
try {
final JexlScript script = jexl.createScript(
"const x; x = 1");
Assert.fail("should fail, x is not defined");
} catch(JexlException.Parsing xparse) {
Assert.assertTrue(xparse.getMessage().contains("x"));
}
}
{code}
If so, why then not simply change the grammar part to something like this ?
{code:java}
void Var() #void : {}
{
DeclareVar(false, false) ( Expression() #Assignment(2))?
|
DeclareVar(true, false) ( Expression() #Assignment(2))?
|
DeclareVar(true, true) Expression() #Assignment(2)
}
{code}
Sorry if I ask too many questions...
was (Author: dmitri_blinov):
[~henrib] I'm terribly sorry but can not grasp your idea with current const
declarations. We are allowing the variable to be declared but blocking its any
further usage and initialization.
{code:java}
@Test
public void testConst2() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
try {
final JexlScript script = jexl.createScript(
"const x; x = 1");
Assert.fail("should fail, x is not defined");
} catch(JexlException.Parsing xparse) {
Assert.assertTrue(xparse.getMessage().contains("x"));
}
}
{code}
If so, why then not simply change the grammar part to something like this ?
{code:java}
void Var() #void : {}
{
DeclareVar(false, false) ( Expression() #Assignment(2))?
|
DeclareVar(true, false) ( Expression() #Assignment(2))?
|
DeclareVar(true, true) Expression() #Assignment(2)
}
{code}
Sorry if I ask too many questions...
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537687#comment-17537687
]
Dmitri Blinov commented on JEXL-369:
[~henrib] I'm terribly sorry but can not grasp your idea with current const
declarations. We are allowing the variable to be declared but blocking its any
further usage and initialization.
{code:java}
@Test
public void testConst2() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
try {
final JexlScript script = jexl.createScript(
"const x; x = 1");
Assert.fail("should fail, x is not defined");
} catch(JexlException.Parsing xparse) {
Assert.assertTrue(xparse.getMessage().contains("x"));
}
}
{code}
If so, why then not simply change the grammar part to something like this ?
{code:java}
void Var() #void : {}
{
DeclareVar(false, false) ( Expression() #Assignment(2))?
|
DeclareVar(true, false) ( Expression() #Assignment(2))?
|
DeclareVar(true, true) Expression() #Assignment(2)
}
{code}
Sorry if I ask too many questions...
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536787#comment-17536787
]
Dmitri Blinov commented on JEXL-369:
I'm also sceptical about the following test case (and similar...)
{code:java}
@Test
public void testForVariable0a() {
final JexlEngine jexl = new JexlBuilder().strict(true).create();
try {
final JexlScript script = jexl.createScript("for(let x : 1..3) {
let c = 0}; return x");
Assert.fail("Should not have been parsed");
} catch (final JexlException ex) {
// OK
}
}
{code}
I would have expect the code to fail only if lexical shade mode is explicitly
enabled, like this
{code:java}
@Test
public void testForVariable0a() {
final JexlFeatures f = new JexlFeatures();
f.lexicalShade(true);
final JexlEngine jexl = new
JexlBuilder().strict(true).features(f).create();
try {
final JexlScript script = jexl.createScript("for(let x : 1..3) {
let c = 0}; return x");
Assert.fail("Should not have been parsed");
} catch (final JexlException ex) {
// OK
}
} {code}
The lexical shade mode is not what everyone may wish to enforce
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536284#comment-17536284
]
Dmitri Blinov commented on JEXL-369:
It seems there is a bug with const checks. The following test fails.
{code:java}
@Test
public void testConst0() {
final JexlFeatures f = new JexlFeatures();
final JexlEngine jexl = new JexlBuilder().strict(true).create();
final JexlScript script = jexl.createScript(
"{ const x = 10; }; { let x = 20; x = 22}");
final JexlContext jc = new MapContext();
final Object result = script.execute(jc);
Assert.assertEquals(22, result);
}
{code}
We should keep variable modifiers in the lexical scope where variable is
defined. If my implementation could be of an
[example...|https://github.com/dmitri-blinov/commons-jexl/blob/main/src/main/java/org/apache/commons/jexl3/internal/LexicalScope.java]
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535050#comment-17535050 ] Dmitri Blinov edited comment on JEXL-369 at 5/11/22 6:32 PM: - [~henrib] My pleasure! As a good rule, const variable declarations should require an initialization part. Some sophisticated compilers like in java allow to separate the definition and initialization of final vars, but for JEXL this is beyond the reach, so the only way is to enforce initialization at the declaration point. was (Author: dmitri_blinov): [~henrib] As a good rule, const variable declarations should require an initialization part. Some sophisticated compilers like in java allow to separate the definition and initialization of final vars, but for JEXL this is beyond the reach, so the only way is to enforce initialization at the declaration point. > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535050#comment-17535050 ] Dmitri Blinov commented on JEXL-369: [~henrib] As a good rule, const variable decarations should require an initialization part. Some sophisticated compilers like in java allow to separate the definition and initialization of final vars, but for JEXL this is beyond the reach, so the only way is to enforce initialization at the declaration point. > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535050#comment-17535050 ] Dmitri Blinov edited comment on JEXL-369 at 5/11/22 6:18 PM: - [~henrib] As a good rule, const variable declarations should require an initialization part. Some sophisticated compilers like in java allow to separate the definition and initialization of final vars, but for JEXL this is beyond the reach, so the only way is to enforce initialization at the declaration point. was (Author: dmitri_blinov): [~henrib] As a good rule, const variable decarations should require an initialization part. Some sophisticated compilers like in java allow to separate the definition and initialization of final vars, but for JEXL this is beyond the reach, so the only way is to enforce initialization at the declaration point. > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533205#comment-17533205 ] Dmitri Blinov edited comment on JEXL-369 at 5/7/22 7:29 AM: You are right about case 4. It differs from the case 2 in a sense that the inner scoped var is declared first, and the outer scoped var is declared afterwards. But it should be disallowed also. Added case 0 as compatibility check was (Author: dmitri_blinov): You are right about case 4. It differs from the case 2 in a sense that the inner scoped var is declared first, and the outer scoped var is declared afterwards. But it should be disallowed also > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532992#comment-17532992
]
Dmitri Blinov edited comment on JEXL-369 at 5/7/22 7:28 AM:
So, to sum up, what should we expect (in non-lexical mode)?
Case 0
{code:java}
var x = 1; // allowed
var x = 2; // allowed {code}
Case 1
{code:java}
var x = 1; // allowed
let x = 2; // disallowed {code}
Case 2
{code:java}
let x = 1; // allowed
var x = 2; // disallowed {code}
Case 3
{code:java}
let x = 1; // allowed
{
let x = 2; // disallowed
} {code}
Case 4
{code:java}
{
let x = 1; // allowed
var x = 2; // disallowed
} {code}
Case 5
{code:java}
{
let x = 1; // allowed
}
var x = 2; // allowed
{code}
Right? In lexical mode there should be no difference between var and let, I
guess.
was (Author: dmitri_blinov):
So, to sum up, what should we expect (in non-lexical mode)?
Case 1
{code:java}
var x = 1; // allowed
let x = 2; // disallowed {code}
Case 2
{code:java}
let x = 1; // allowed
var x = 2; // disallowed {code}
Case 3
{code:java}
let x = 1; // allowed
{
let x = 2; // disallowed
} {code}
Case 4
{code:java}
{
let x = 1; // allowed
var x = 2; // disallowed
} {code}
Case 5
{code:java}
{
let x = 1; // allowed
}
var x = 2; // allowed
{code}
Right? In lexical mode there should be no difference between var and let, I
guess.
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533205#comment-17533205 ] Dmitri Blinov edited comment on JEXL-369 at 5/7/22 6:57 AM: You are right about case 4. It differs from the case 2 in a sense that the inner scoped var is declared first, and the outer scoped var is declared afterwards. But it should be disallowed also was (Author: dmitri_blinov): You are right about case 4. > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533205#comment-17533205 ] Dmitri Blinov commented on JEXL-369: You are right about case 4. > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532992#comment-17532992
]
Dmitri Blinov edited comment on JEXL-369 at 5/7/22 6:51 AM:
So, to sum up, what should we expect (in non-lexical mode)?
Case 1
{code:java}
var x = 1; // allowed
let x = 2; // disallowed {code}
Case 2
{code:java}
let x = 1; // allowed
var x = 2; // disallowed {code}
Case 3
{code:java}
let x = 1; // allowed
{
let x = 2; // disallowed
} {code}
Case 4
{code:java}
{
let x = 1; // allowed
var x = 2; // disallowed
} {code}
Case 5
{code:java}
{
let x = 1; // allowed
}
var x = 2; // allowed
{code}
Right? In lexical mode there should be no difference between var and let, I
guess.
was (Author: dmitri_blinov):
So, to sum up, what should we expect (in non-lexical mode)?
Case 1
{code:java}
var x = 1; // allowed
let x = 2; // disallowed {code}
Case 2
{code:java}
let x = 1; // allowed
var x = 2; // disallowed {code}
Case 3
{code:java}
let x = 1; // allowed
{
let x = 2; // disallowed
} {code}
Case 4
{code:java}
{
let x = 1; // allowed
var x = 2; // allowed
} {code}
Case 5
{code:java}
{
let x = 1; // allowed
}
var x = 2; // allowed
{code}
Right? In lexical mode there should be no difference between var and let, I
guess.
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532992#comment-17532992
]
Dmitri Blinov edited comment on JEXL-369 at 5/6/22 5:18 PM:
So, to sum up, what should we expect (in non-lexical mode)?
Case 1
{code:java}
var x = 1; // allowed
let x = 2; // disallowed {code}
Case 2
{code:java}
let x = 1; // allowed
var x = 2; // disallowed {code}
Case 3
{code:java}
let x = 1; // allowed
{
let x = 2; // disallowed
} {code}
Case 4
{code:java}
{
let x = 1; // allowed
var x = 2; // allowed
} {code}
Case 5
{code:java}
{
let x = 1; // allowed
}
var x = 2; // allowed
{code}
Right? In lexical mode there should be no difference between var and let, I
guess.
was (Author: dmitri_blinov):
So, to sum up, what should we expect (in non-lexical mode)?
Case 1
{code:java}
var x = 1; // allowed
let x = 2; // disallowed {code}
Case 2
{code:java}
let x = 1; // allowed
var x = 2; // disallowed {code}
Case 3
{code:java}
let x = 1; // allowed
{
let x = 2; // disallowed
} {code}
Case 4
{code:java}
{
let x = 1; // allowed
var x = 2; // allowed
} {code}
Right? In lexical mode there should be no difference between var and let, I
guess.
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532992#comment-17532992
]
Dmitri Blinov commented on JEXL-369:
So, to sum up, what should we expect (in non-lexical mode)?
Case 1
{code:java}
var x = 1; // allowed
let x = 2; // disallowed {code}
Case 2
{code:java}
let x = 1; // allowed
var x = 2; // disallowed {code}
Case 3
{code:java}
let x = 1; // allowed
{
let x = 2; // disallowed
} {code}
Case 4
{code:java}
{
let x = 1; // allowed
var x = 2; // allowed
} {code}
Right? In lexical mode there should be no difference between var and let, I
guess.
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532652#comment-17532652
]
Dmitri Blinov edited comment on JEXL-369 at 5/6/22 9:36 AM:
In JS they allowed redefinition with let/const, ie
{code:java}
const pi = 3.1415
{
// I know better
let pi = 3.2
// or may be it's even not a constant after all
pi = pi + 0.1
}{code}
Just to make sure, you don’t want to do this with JEXL with introduction of
let, right?
was (Author: dmitri_blinov):
In JS they allowed redefinition with let/const, ie
{code:java}
const pi = 3.1415
{
// I know better
let pi = 3.2
// or may be it's even not a constant after all
pi = pi + 0.1
}{code}
You don’t want to do this with JEXL with introduction of let, right?
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532652#comment-17532652
]
Dmitri Blinov edited comment on JEXL-369 at 5/6/22 8:43 AM:
In JS they allowed redefinition with let/const, ie
{code:java}
const pi = 3.1415
{
// I know better
let pi = 3.2
// or may be it's even not a constant after all
pi = pi + 0.1
}{code}
You don’t want to do this with JEXL with introduction of let, right?
was (Author: dmitri_blinov):
In JS they allowed redefinition with let/const, ie
{code:java}
const pi = 3.1415
{
// I know better
let pi = 3.2
// or may be
pi = pi + 0.1
}{code}
You don’t want to do this with JEXL with introduction of let, right?
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532652#comment-17532652
]
Dmitri Blinov edited comment on JEXL-369 at 5/6/22 5:38 AM:
In JS they allowed redefinition with let/const, ie
{code:java}
const pi = 3.1415
{
// I know better
let pi = 3.2
// or may be
pi = pi + 0.1
}{code}
You don’t want to do this with JEXL with introduction of let, right?
was (Author: dmitri_blinov):
In JS they allowed redefinition with let/const, ie
{code:java}
const pi = 3.1415
{
// I know better
let pi = 3.2
}{code}
You don’t want to do this with JEXL with introduction of let, right?
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532652#comment-17532652
]
Dmitri Blinov commented on JEXL-369:
In JS they allowed redefinition with let/const, ie
{code:java}
const pi = 3.1415
{
// I know better
let pi = 3.2
}{code}
You don’t want to do this with JEXL with introduction of let, right?
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532407#comment-17532407
]
Dmitri Blinov edited comment on JEXL-369 at 5/5/22 4:50 PM:
In JS you may have a variable redeclared in nested block unlimited number of
times
{code:java}
let x = 1
{
let x = 2;
{
let x = 3;
}
// x = 2
}
// x = 1
{code}
In JEXL, if I’m not mistaken, in lexical mode (like n java) it is not possible
to declare a variable in nested block if it has already been defined in outer
block.
{code:java}
var x = 1;
{
// error here
var x = 2;
}{code}
To illustrate how JS variables work (redeclaration, hoisting and capturing)
lets consider the dummy example
{code:java}
var x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// expected output: 2
{
// let x = 3;
var ddd = function() {return x = x +1}
let x = 4;
}
console.log(x)
console.log(ddd());
}
console.log(x);
// expected output: 1
console.log(ddd());
{code}
The output is 2, 2, 5, 1, 6
was (Author: dmitri_blinov):
In JS you may have a variable redeclared in nested block unlimited number of
times
{code:java}
let x = 1
{
let x = 2;
{
let x = 3;
}
// x = 2
}
// x = 1
{code}
In JEXL in lexical mode (like n java) it is not possible to declare a variable
in nested block if it has already been defined in outer block.
{code:java}
var x = 1;
{
// error here
var x = 2;
}{code}
To illustrate how JS variables work (redeclaration, hoisting and capturing)
lets consider the dummy example
{code:java}
var x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// expected output: 2
{
// let x = 3;
var ddd = function() {return x = x +1}
let x = 4;
}
console.log(x)
console.log(ddd());
}
console.log(x);
// expected output: 1
console.log(ddd());
{code}
The output is 2, 2, 5, 1, 6
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532407#comment-17532407
]
Dmitri Blinov edited comment on JEXL-369 at 5/5/22 4:48 PM:
In JS you may have a variable redeclared in nested block unlimited number of
times
{code:java}
let x = 1
{
let x = 2;
{
let x = 3;
}
// x = 2
}
// x = 1
{code}
In JEXL in lexical mode (like n java) it is not possible to declare a variable
in nested block if it has already been defined in outer block.
{code:java}
var x = 1;
{
// error here
var x = 2;
}{code}
To illustrate how JS variables work (redeclaration, hoisting and capturing)
lets consider the dummy example
{code:java}
var x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// expected output: 2
{
// let x = 3;
var ddd = function() {return x = x +1}
let x = 4;
}
console.log(x)
console.log(ddd());
}
console.log(x);
// expected output: 1
console.log(ddd());
{code}
The output is 2, 2, 5, 1, 6
was (Author: dmitri_blinov):
In JS you may have a variable redeclared in nested block unlimited number of
times
{code:java}
let x = 1
{
let x = 2;
{
let x = 3;
}
// x = 2
}
// x = 1
{code}
In JEXL (like n java) it is not possible to declare a variable in nested block
if it has already been defined in outer block.
To illustrate how JS variables work lets consider the dummy example
{code:java}
var x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// expected output: 2
{
// let x = 3;
var ddd =function() {return x = x +1}
let x = 4;
}
console.log(x)
console.log(ddd());
}
console.log(x);
// expected output: 1
console.log(ddd());
{code}
The output is 2, 2, 5, 1, 6
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532407#comment-17532407
]
Dmitri Blinov edited comment on JEXL-369 at 5/5/22 4:32 PM:
In JS you may have a variable redeclared in nested block unlimited number of
times
{code:java}
let x = 1
{
let x = 2;
{
let x = 3;
}
// x = 2
}
// x = 1
{code}
In JEXL (like n java) it is not possible to declare a variable in nested block
if it has already been defined in outer block.
To illustrate how JS variables work lets consider the dummy example
{code:java}
var x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// expected output: 2
{
// let x = 3;
var ddd =function() {return x = x +1}
let x = 4;
}
console.log(x)
console.log(ddd());
}
console.log(x);
// expected output: 1
console.log(ddd());
{code}
The output is 2, 2, 5, 1, 6
was (Author: dmitri_blinov):
In JS you may have a variable redeclared in nested block unlimited number of
times
{code:java}
let x = 1
{
let x = 2;
{
let x = 3;
}
// x = 2
}
x = 1
{code}
In JEXL (like n java) it is not possible to declare a variable in nested block
if it has already been defined in outer block.
To illustrate how JS variables work lets consider the dummy example
{code:java}
var x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// expected output: 2
{
// let x = 3;
var ddd =function() {return x = x +1}
let x = 4;
}
console.log(x)
console.log(ddd());
}
console.log(x);
// expected output: 1
console.log(ddd());
{code}
The output is 2, 2, 5, 1, 6
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532407#comment-17532407
]
Dmitri Blinov commented on JEXL-369:
In JS you may have a variable redeclared in nested block unlimited number of
times
{code:java}
let x = 1
{
let x = 2;
{
let x = 3;
}
// x = 2
}
x = 1
{code}
In JEXL (like n java) it is not possible to declare a variable in nested block
if it has already been defined in outer block.
To illustrate how JS variables work lets consider the dummy example
{code:java}
var x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// expected output: 2
{
// let x = 3;
var ddd =function() {return x = x +1}
let x = 4;
}
console.log(x)
console.log(ddd());
}
console.log(x);
// expected output: 1
console.log(ddd());
{code}
The output is 2, 2, 5, 1, 6
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532264#comment-17532264
]
Dmitri Blinov edited comment on JEXL-369 at 5/5/22 2:15 PM:
Henri, could you please provide the vision of what should be changed with
introduction of let ? Are we adding nested block-scoped variables like in JS or
simply {{let}} is a new \{{var}} in lexical mode ?
May be this is not strictly relates to the ticket, but one of the things with
lexically scoped variables that I think we should consider is grammar change to
disallow single-statement variable declarations in lexical mode (as of now or
with let). For example {{if (cond1) var x = 0;}} If we look at other languages,
like JS or Java, this is not allowed. The statements where single-statement
variable declarations should be disallowed are {{{}if/else{}}}, {{{}while{}}},
{{{}do{}}}, {{{}for{}}}. For compatibility reasons in non-lexical mode we can
keep the existing grammar. If my work may be of any reference, here is what I
did. FunctionStatement() is named function declaration like \{{function x() ...
}} and so I also restricted it in lexical mode.
{code:java}
void StatementBranch() #void : {}{LOOKAHEAD(1) Block() |
LOOKAHEAD({!getFeatures().isLexical()}) GenericStatement() | Statement()}
void GenericStatement() #void : {}{| AnnotatedStatement()|
LOOKAHEAD(FunctionStatementLookahead()) FunctionStatement()|
LOOKAHEAD(DeclareLocalVar()) VarStatement()
| LOOKAHEAD(Expression()) ExpressionStatement()
...
void Statement() #void : {}{| AnnotatedStatement()|
| LOOKAHEAD(Expression()) ExpressionStatement()
...{code}
was (Author: dmitri_blinov):
Henri, could you please provide the vision of what should be changed with
introduction of let ? Are we adding nested block-scoped variables like in JS or
simply {{let}} is a new \{{var }} in lexical mode ?
May be this is not strictly relates to the ticket, but one of the things with
lexically scoped variables that I think we should consider is grammar change to
disallow single-statement variable declarations in lexical mode (as of now or
with let). For example {{if (cond1) var x = 0;}} If we look at other languages,
like JS or Java, this is not allowed. The statements where single-statement
variable declarations should be disallowed are {{if/else}}, {{{}while{}}},
{{{}do{}}}, {{{}for{}}}. For compatibility reasons in non-lexical mode we can
keep the existing grammar. If my work may be of any reference, here is what I
did. FunctionStatement() is named function declaration like {{function x() ...
}} and so I also restricted it in lexical mode.
{code:java}
void StatementBranch() #void : {}{LOOKAHEAD(1) Block() |
LOOKAHEAD({!getFeatures().isLexical()}) GenericStatement() | Statement()}
void GenericStatement() #void : {}{| AnnotatedStatement()|
LOOKAHEAD(FunctionStatementLookahead()) FunctionStatement()|
LOOKAHEAD(DeclareLocalVar()) VarStatement()
| LOOKAHEAD(Expression()) ExpressionStatement()
...
void Statement() #void : {}{| AnnotatedStatement()|
| LOOKAHEAD(Expression()) ExpressionStatement()
...{code}
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-369) Add 'let' and 'const' variable declarations
[
https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532264#comment-17532264
]
Dmitri Blinov commented on JEXL-369:
Henri, could you please provide the vision of what should be changed with
introduction of let ? Are we adding nested block-scoped variables like in JS or
simply {{let}} is a new \{{var }} in lexical mode ?
May be this is not strictly relates to the ticket, but one of the things with
lexically scoped variables that I think we should consider is grammar change to
disallow single-statement variable declarations in lexical mode (as of now or
with let). For example {{if (cond1) var x = 0;}} If we look at other languages,
like JS or Java, this is not allowed. The statements where single-statement
variable declarations should be disallowed are {{if/else}}, {{{}while{}}},
{{{}do{}}}, {{{}for{}}}. For compatibility reasons in non-lexical mode we can
keep the existing grammar. If my work may be of any reference, here is what I
did. FunctionStatement() is named function declaration like {{function x() ...
}} and so I also restricted it in lexical mode.
{code:java}
void StatementBranch() #void : {}{LOOKAHEAD(1) Block() |
LOOKAHEAD({!getFeatures().isLexical()}) GenericStatement() | Statement()}
void GenericStatement() #void : {}{| AnnotatedStatement()|
LOOKAHEAD(FunctionStatementLookahead()) FunctionStatement()|
LOOKAHEAD(DeclareLocalVar()) VarStatement()
| LOOKAHEAD(Expression()) ExpressionStatement()
...
void Statement() #void : {}{| AnnotatedStatement()|
| LOOKAHEAD(Expression()) ExpressionStatement()
...{code}
> Add 'let' and 'const' variable declarations
> ---
>
> Key: JEXL-369
> URL: https://issues.apache.org/jira/browse/JEXL-369
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> Add creation of lexical scope variables, modifiable with 'let',
> non-modifiable through 'const'.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531394#comment-17531394 ] Dmitri Blinov commented on JEXL-367: [~hussachai] thanks for the thorough observation, but my question was rather about why trying to make JEXL yet another JS, groovy or you name it. One probably won’t get close to the original, and what is the point of being half alike? There are open projects like aforementioned rhino, that one can freely use now-days and enjoy bells and whistles. But IMO, in JEXL world you will hardly make variables work like JS ones, regarding redefinition, hoisting and capturing behavior, without overcomplicating the long existing concept of context and local variables with toggles and features. [~henrib] I think JS have coined some cool features, that JEXL can surely benefit from, but IMO its variable model is not one of them, are you sure you want let it ‘let’ ?:) > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530901#comment-17530901 ] Dmitri Blinov commented on JEXL-367: [~henrib] May I ask what is so special about JS, why not java, groovy or may be python ?:) > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530490#comment-17530490 ] Dmitri Blinov commented on JEXL-367: [~henrib] In short, in JS world fat arrow functions have their own ‘this’ scope, and don’t have bindings to ‘arguments’. There are also restrictions to use some operators etc. I think it’s pretty much documented in JS reference[JS reference|[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions]|https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions].] The point is - arrow functions are not syntactic sugar for usual functions in JS. In JEXL world the differences above may not apply, since, for example, there is no ‘this’, yet. But as a thought - if we seriously decided to chase JS, IMO there are plenty of other missing features - operators, statements, constructor calls, varargs. For all it worth, I have had even added them in my fork the other day, so if anyone is interested please have a look. > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530387#comment-17530387 ] Dmitri Blinov edited comment on JEXL-367 at 4/30/22 1:10 PM: - Fat arrows have special meaning in JS and are not stict equivalents to traditional functions. IMO It would be strange to deprecate existing functionality in favor of new one just for the sake of questionnable similarity to JS in one aspect. I'd understand if we wanted to add new semanitcs to the languags with the intoduction of a new syntax, or at least aliasing exising syntax for good compatibility reason. Why not renaming `var` to `let` then? was (Author: dmitri_blinov): Fat arrows have special meaning in JS and are not stict equivalents to traditional functions. IMO It would be strange to deprecate existing functionality in favor of new one just for the sake of questionnable similarity to JS in one aspect. What's will be next? renaming `var` to `let`? > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530387#comment-17530387 ] Dmitri Blinov commented on JEXL-367: Fat arrows have special meaning in JS and are not stict equivalents to traditional functions. IMO It would be strange to deprecate existing functionality in favor of new one just for the sake of questionnable similarity to JS in one aspect. What's will be next? renaming `var` to `let`? > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-360) Add missing bitshift operators ( >>, >>>, <<)
[ https://issues.apache.org/jira/browse/JEXL-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492758#comment-17492758 ] Dmitri Blinov commented on JEXL-360: It seems you've already done most of the work. I've added some tests and type-aware shifts arithmetic > Add missing bitshift operators ( >>, >>>, <<) > - > > Key: JEXL-360 > URL: https://issues.apache.org/jira/browse/JEXL-360 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Ian Hawkins >Priority: Minor > Labels: newbie > > Hi! > Jexl appears to be missing the >> << >>> <<< bit shift operators - it > would be really useful to have them so we can do things like (b >> > bitnumber), etc. > Thanks! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (JEXL-360) Add missing bitwise operators ( >>, >>>, etc)
[ https://issues.apache.org/jira/browse/JEXL-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492400#comment-17492400 ] Dmitri Blinov edited comment on JEXL-360 at 2/15/22, 9:24 AM: -- This is what, among many other things, that I have added in the experimental fork ([See https://github.com/dmitri-blinov/commons-jexl|https://github.com/dmitri-blinov/commons-jexl]), you can look at it and tell what you think. I could prepare PR for this if Henri would be so kind to accept it. Henri, what is your current vision about further language extensions (new operators / refactoring) ? was (Author: dmitri_blinov): This is what, among many other things, that I have added in the experimental fork ([See https://github.com/dmitri-blinov/commons-jexl|https://github.com/dmitri-blinov/commons-jexl]), you can look at it and tell what you think. I could prepare PR for this if Henry would be so kind to accept it. Henry, what is your current vision about further language extensions (new operators / refactoring) ? > Add missing bitwise operators ( >>, >>>, etc) > - > > Key: JEXL-360 > URL: https://issues.apache.org/jira/browse/JEXL-360 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Ian Hawkins >Priority: Minor > Labels: newbie > > Hi! > Jexl appears to be missing the >> << >>> <<< bit shift operators - it > would be really useful to have them so we can do things like (b >> > bitnumber), etc. > Thanks! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JEXL-360) Add missing bitwise operators ( >>, >>>, etc)
[ https://issues.apache.org/jira/browse/JEXL-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492400#comment-17492400 ] Dmitri Blinov commented on JEXL-360: This is what, among many other things, that I have added in the experimental fork ([See https://github.com/dmitri-blinov/commons-jexl|https://github.com/dmitri-blinov/commons-jexl]), you can look at it and tell what you think. I could prepare PR for this if Henry would be so kind to accept it. Henry, what is your current vision about further language extensions (new operators / refactoring) ? > Add missing bitwise operators ( >>, >>>, etc) > - > > Key: JEXL-360 > URL: https://issues.apache.org/jira/browse/JEXL-360 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Ian Hawkins >Priority: Minor > Labels: newbie > > Hi! > Jexl appears to be missing the >> << >>> <<< bit shift operators - it > would be really useful to have them so we can do things like (b >> > bitnumber), etc. > Thanks! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JEXL-357) Configure accessible packages/classes/methods/fields
[ https://issues.apache.org/jira/browse/JEXL-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491610#comment-17491610 ] Dmitri Blinov commented on JEXL-357: The current implementation does not honor classes with no Package information. According to spec the method Class.getPackage() returns null if no package information is available from the archive or codebase. Null checks against class package are required in Persmissions.java > Configure accessible packages/classes/methods/fields > - > > Key: JEXL-357 > URL: https://issues.apache.org/jira/browse/JEXL-357 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > The @NoJexl annotation allows 'hiding' functional elements from scripts; this > features will allow Jexl introspection to completely ignore existing > packages/classes/methods/fields ensuring they can not be called. > Acting (more or less) as a security manager, this will allow fine > configuration of what scripts are allowed to access on a platform. Used in > conjunction with Sandboxing, how much is exposed can be limited to explicit > permission. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (JEXL-233) Documentation rewrite
[ https://issues.apache.org/jira/browse/JEXL-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov closed JEXL-233. -- Resolution: Fixed > Documentation rewrite > - > > Key: JEXL-233 > URL: https://issues.apache.org/jira/browse/JEXL-233 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Minor > Attachments: syntax.xml > > > I have reorganized the JEXL syntax doc, basically adjusted the document > structure to be more logical in my view, and brushed up some descriptions. > Comments are welcome! If it is ok, please promote the attachment to the > source tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JEXL-316) Operator ?? has very low priority
[
https://issues.apache.org/jira/browse/JEXL-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-316.
--
Fix Version/s: (was: Later)
Resolution: Won't Do
> Operator ?? has very low priority
> -
>
> Key: JEXL-316
> URL: https://issues.apache.org/jira/browse/JEXL-316
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
>
> In current version of JEXL the script
> {code:java}
> 10??0 + 200 {code}
> evaluates to 10, which is counterintuitive. It requires to always use
> parantheses after {{\\??}}. The operator {{??}} should have higer priority.
> It is the same problem as with current version of freemarker, but they
> promise to fix it in the next major release.
> The suggestion is to set priority of operator {{??}} to be between
> {{UnaryExpression()}} and {{ValueExpression()}}
> {code}
> void ConditionalExpression() #void : {}
> {
> ConditionalOrExpression()
> (
> Expression() Expression() #TernaryNode(3)
> |
> Expression() #TernaryNode(2)
> )?
> }
> ...
> void UnaryExpression() #void : {}
> {
> UnaryExpression() #UnaryMinusNode(1)
> |
> UnaryExpression() #UnaryPlusNode(1)
> |
> UnaryExpression() #BitwiseComplNode(1)
> |
> (|) UnaryExpression() #NotNode(1)
> |
> UnaryExpression() #EmptyFunction(1)
> |
> UnaryExpression() #SizeFunction(1)
> |
> NullpExpression()
> }
> void NullpExpression() #void : {}
> {
> ValueExpression()
> (
> ValueExpression() #NullpNode(2)
> )*
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-185) Ability to trace execution of script statements
[ https://issues.apache.org/jira/browse/JEXL-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov closed JEXL-185. -- Resolution: Won't Do > Ability to trace execution of script statements > --- > > Key: JEXL-185 > URL: https://issues.apache.org/jira/browse/JEXL-185 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dmitri Blinov >Priority: Minor > > Since the rising complexity of the JEXL scripts makes it easier to write > sophisticated scripts, and harder to debug overall script evaluation, it > would be helpful to provide some way to trace individual statements execution > within the script by a callback interface. > Callback could be applied to JEXL engine as a whole, or to > Script.executeScript method as an additional parameter for example. > Callback interface should contain a method which should be invoked by JEXL on > completion of individual statement. Method parameters should contain such > values as DebugInfo (start..end statement position within the script), > statement execution result or exception (which in silent mode may be > swallowed), initial context, and possibly a stack frame to be able to peep > into local variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JEXL-266) Allow to remove an element from iterator collection within for-loops
[
https://issues.apache.org/jira/browse/JEXL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-266.
--
Resolution: Won't Do
> Allow to remove an element from iterator collection within for-loops
>
>
> Key: JEXL-266
> URL: https://issues.apache.org/jira/browse/JEXL-266
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
> Environment: I have created a patch as initial implementation for
> this new feature, please see github pull request here
> [pr#5|https://github.com/apache/commons-jexl/pull/5]. I whould be very
> grateful if this could be interesting for the community and included in
> master branch. Thanks in advance!
>Reporter: Dmitri Blinov
>Priority: Minor
>
> The for-loop in JEXL provides a convenient way to iterate over different
> types of collections, however, its not possible for a script writer to
> utilize underlying
> {code:java}
> iterator.remove(){code}
> method within such a loop. The proposal is to introduce new {{remove}}
> statement which should be used within for-loops and should internally call
> {{iterator.remove()}} method and skip the loop to the next element;
> For example, the following code should remove items {{1,2,3}} from set and
> return value {{3}}.
> {code:java}
> var set = {1,2,3,4,5,6}; for (var item : set) if (item <= 3) remove; return
> size(set)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-268) Jexl lambdas as parameters to new Java8 methods
[
https://issues.apache.org/jira/browse/JEXL-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-268.
--
Resolution: Won't Do
> Jexl lambdas as parameters to new Java8 methods
> ---
>
> Key: JEXL-268
> URL: https://issues.apache.org/jira/browse/JEXL-268
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Fix For: Later
>
>
> Java8 introduced functional interfaces, among them {{Function}} and
> {{BiFunction}} interfaces which are used as parameters to method calls, for
> example, {{Map.computeIfAbsent()}} or {{Map.computeIfPresent()}}. In Jexl we
> have lambdas which in theory are good candidates to construct a {{Function}}
> for lambda with one parameter, and a {{BiFunction}} for lambda with two
> parameters.
> The problem is Jexl can not currently support Java8 features and all
> instances of lambda are of single {{internal.Closure}} class, which should
> not try to implement both interfaces at once. One of the solutions, IMO, is
> to have a feature to overload lamda creations to construct custom lambda
> classes without shaking Jexl code tree.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-276) Introduce short-handed ternary operation x ? y
[
https://issues.apache.org/jira/browse/JEXL-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-276.
--
Resolution: Won't Do
> Introduce short-handed ternary operation x ? y
> --
>
> Key: JEXL-276
> URL: https://issues.apache.org/jira/browse/JEXL-276
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> A short-handed ternary operation {{x ? y}} is an equivalent of the {{x ? y :
> null}}. The {{x : y}} operator is analogous to {{if (x) y}} statement with
> {{else}} part omitted. With new syntax we will have ternary operator and
> {{if}} statement to have full symmetry of forms, e.g.
> {{x ? y : x}} is {{if (x) y else z}}, {{x ? y}} is {{if (x) y}}
> Just to note, the proposed short-handed differs from Elvis operator {{x ?:
> y}} which is effectively {{x ? x : y}}. In other words, elvis operator allows
> for the middle part of the ternary operator to be omitted, whereas the
> proposed form allows for the imission of the last part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-269) Indexed for-loop
[
https://issues.apache.org/jira/browse/JEXL-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-269.
--
Resolution: Won't Do
> Indexed for-loop
>
>
> Key: JEXL-269
> URL: https://issues.apache.org/jira/browse/JEXL-269
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
> Environment: I have created a PR for this feature, please see
> [PR#12|https://github.com/apache/commons-jexl/pull/12]
>Reporter: Dmitri Blinov
>Priority: Minor
>
> Introduce new extended syntax of 'for' statement, which allows to specify two
> variables, like the following
> {code:java}
> for (var i, item : list){code}
> Inside the loop, the first variable gets current iteration counter, starting
> from 0, and the second variable gets current iterated value. The special
> consideration is taken for iteration over map entries, like the following
> {code:java}
> for(var key, entry : map){code}
> , in this case the first variable is the map key, and the second is the
> corresponding map value
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[
https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289743#comment-17289743
]
Dmitri Blinov commented on JEXL-342:
I've made some fiddling with new features for JEXL the other day, but many of
them were not accepted at that time even with Jira tasks and PRs on github, so
generally this is not an easy task, it's kind of making an omelette without
breaking eggs job. Nevertheless the desire to get something done, to fill the
gaps between JEXL and well-accepted modern ideas in other languages (Java 8
itself to start with) brought me to idea to get a fork, so anyone interesting
in evolving JEXL could look at ([link to
repository|https://github.com/dmitri-blinov/commons-jexl]). I'd love to have
all or any of those features to be part of the upstream one day, though as I
have said before, I fully understand that not everyone would be happy to get
the eggs broken. But the progress is inevitable, and for the long run choice is
tough - either JEXL will evolve or stall as a project. The solution in my
opinion is well known and would be to have a major version bump for some modern
experimental stuff and stable version for current implementation.
> Support for Java Optional.
> --
>
> Key: JEXL-342
> URL: https://issues.apache.org/jira/browse/JEXL-342
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Garret Wilson
>Priority: Major
>
> Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can
> this this easily be added as some sort of plugin, or better yet can it be
> added to the library?
> h3. {{Optional}} Traversal
> I need to create an API that works well for application developers as for
> those using templates with JEXL expressions. Let's say that the {{Bar}} class
> has a {{Bar.getName()}}. And the {{Foo}} class has this method:
> {code:java}
> Optional getBar(String barId);
> {code}
> In code getting the "test" foo-bar name would be like this:
> {code:java}
> String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null);
> {code}
> I want the navigation across {{Optional<>}} to work just as if it were a
> nullable variable. That is, I want the following JEXL expression to give the
> same result as {{fooBarName}} above:
> {code}
> foo.bar("test").name
> {code}
> If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}},
> I think JEXL would work for this already. but the whole point of
> {{Optional<>}} is that I keep nullables out of my code, so I don't want to
> create inferior APIs inconsistent with the rest of my project just to work
> with JEXL.
> h3. {{Optional}} Getter Name
> As icing on the cake, I would like to have {{Optional<>}} returning getter
> discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne
> suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html].
> I've been using this pattern for several years, and I really like it. Thus to
> indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable
> but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this:
> {code:java}
> Optional findBar(String barId);
> {code}
> I would thus want the exact same JEXL expression above to still work:
> {code}
> foo.bar("test").name
> {code}
> Otherwise I'll have to forego use of modern Java constructs and make an
> outdated style and less safe API just to get JEXL to work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JEXL-329) Uberspect may loose its Classloader
[ https://issues.apache.org/jira/browse/JEXL-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076258#comment-17076258 ] Dmitri Blinov edited comment on JEXL-329 at 4/6/20, 11:42 AM: -- We supply JexlUberspect with our classloader to be able to create our classes in the future, so its possible for a classloader not to have any instances of the classes for the moment, so to be softly referenced, but that doesn’t mean we are ready to throw it away, right? While I can somehow provide that my custom classloader is Hard-referenced from application to prevent its unloading, I dont understand what is the idea behind keeping classloader via softreference in uberpect? What is the use-case for it? was (Author: dmitri_blinov): We supply JexlUberspect with our classloader to be able to create our classes in the future, so its possible for a classloader not to have any instances of the classes for the moment, so to be softly referenced, but that doesn’t mean we are ready to throw it away, right? > Uberspect may loose its Classloader > --- > > Key: JEXL-329 > URL: https://issues.apache.org/jira/browse/JEXL-329 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Major > > In the current implementation Uberspect keeps references to its Introspector > and ClassLoader via SoftReference. This means that when memory is short it > can loose not only Introspector reference, which is OK, but also ClassLoader > that was specified for resolving constructors, which looks like a bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-329) Uberspect may loose its Classloader
[ https://issues.apache.org/jira/browse/JEXL-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076258#comment-17076258 ] Dmitri Blinov commented on JEXL-329: We supply JexlUberspect with our classloader to be able to create our classes in the future, so its possible for a classloader not to have any instances of the classes for the moment, so to be softly referenced, but that doesn’t mean we are ready to throw it away, right? > Uberspect may loose its Classloader > --- > > Key: JEXL-329 > URL: https://issues.apache.org/jira/browse/JEXL-329 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Major > > In the current implementation Uberspect keeps references to its Introspector > and ClassLoader via SoftReference. This means that when memory is short it > can loose not only Introspector reference, which is OK, but also ClassLoader > that was specified for resolving constructors, which looks like a bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JEXL-329) Uberspect may loose its Classloader
Dmitri Blinov created JEXL-329: -- Summary: Uberspect may loose its Classloader Key: JEXL-329 URL: https://issues.apache.org/jira/browse/JEXL-329 Project: Commons JEXL Issue Type: Bug Affects Versions: 3.1 Reporter: Dmitri Blinov In the current implementation Uberspect keeps references to its Introspector and ClassLoader via SoftReference. This means that when memory is short it can loose not only Introspector reference, which is OK, but also ClassLoader that was specified for resolving constructors, which looks like a bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-302) JexlScript.getVariables returns strange values for array access
[
https://issues.apache.org/jira/browse/JEXL-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035185#comment-17035185
]
Dmitri Blinov commented on JEXL-302:
Thanks for the clarification, it was the transion from {{a[['b', 'c']]}} to
{{[a.b, a.c]}} that I wasn't able to figure out. This is not obvious because
getting list of properties via array access is not supported anywhere in the
basic implementation. Not sure whether it's worth adding such a feature though.
But one thing that I think is strange here is that \{{getVariables()}} in fact
*relies* on the hypotesis that one should implement array access to support
sets and arrays in such a way.
> JexlScript.getVariables returns strange values for array access
> ---
>
> Key: JEXL-302
> URL: https://issues.apache.org/jira/browse/JEXL-302
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> I can not understand the logic behind the current implementation of
> {{JexlScript.getVariables()}} method. From the documentation we know that the
> result should be the set of script variables. For the code
> {code:java}
> a[b][c]{code}
> it gives three variables {{a}}, {{b}}, {{c}}. So far so good. But for the code
> {code:java}
> a[b]['c']{code}
> it returns {{a}} and {{b c}}, where second variable has two fragments {{b}}
> and {{c}}. The documentation states that variables with multiple fragments
> are ant-ish variables, but I don't have any of ant-ish variables in the
> example, and {{'c'}} is not a variable, but a constant. I expect to get {{a}}
> and {{b}} as a result.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032339#comment-17032339
]
Dmitri Blinov commented on JEXL-307:
The following test case fails with - *_variable 'x' is undefined_*
{code:java}
@Test
public void testCapturedShaded() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("{var x = 10; } var a =
function(var b) {for (var q : 1 ..10) {return x + b}}; a(32)");
JexlContext jc = new MapContext();
jc.set("x", 11);
Object result = script.execute(null);
Assert.assertEquals(result, 43);
}
{code}
The expected behaviour is to resolve context variable 'x'
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-302) JexlScript.getVariables returns strange values for array access
[
https://issues.apache.org/jira/browse/JEXL-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030755#comment-17030755
]
Dmitri Blinov commented on JEXL-302:
Maybe I'm kicking a dead horse here, but can you please explain the logic
behind {{x.y[['z', 't']]}}
{code:java}
@Test
public void testLiteral() throws Exception {
JexlScript e = JEXL.createScript("x.y[['z', 't']]");
Set> vars = e.getVariables();
Assert.assertEquals(1, vars.size());
Assert.assertTrue(eq(mkref(new String[][]{{"x", "y", "[ 'z', 't' ]"}}),
vars));
} {code}
Why do we expect the last "[ 'z', 't' ]" part? How is it differ from, for
instance, {{x.y['z' + 't']}} in a sense that both {{'z' + 't'}} and {{['z',
't']}} are just expressions?
> JexlScript.getVariables returns strange values for array access
> ---
>
> Key: JEXL-302
> URL: https://issues.apache.org/jira/browse/JEXL-302
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> I can not understand the logic behind the current implementation of
> {{JexlScript.getVariables()}} method. From the documentation we know that the
> result should be the set of script variables. For the code
> {code:java}
> a[b][c]{code}
> it gives three variables {{a}}, {{b}}, {{c}}. So far so good. But for the code
> {code:java}
> a[b]['c']{code}
> it returns {{a}} and {{b c}}, where second variable has two fragments {{b}}
> and {{c}}. The documentation states that variables with multiple fragments
> are ant-ish variables, but I don't have any of ant-ish variables in the
> example, and {{'c'}} is not a variable, but a constant. I expect to get {{a}}
> and {{b}} as a result.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-323) Ant-style variables can throw exception when evaluated for their value
[
https://issues.apache.org/jira/browse/JEXL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028425#comment-17028425
]
Dmitri Blinov commented on JEXL-323:
Not sure whether its worth creating a separate issue for this, but the
following test case fails, because we are mixing null values with undefined
variables when resolving antish variables.
{code:java}
@Test
public void testBadAnt() throws Exception {
JexlEvalContext ctxt = new JexlEvalContext();
JexlOptions options = ctxt.getEngineOptions();
ctxt.set("x.y", 42);
JexlScript script = JEXL.createScript("var x = null; x.y");
try {
Object result = script.execute(ctxt);
Assert.fail("antish var shall not be resolved");
} catch(JexlException xother) {
Assert.assertTrue(xother != null);
}
}
{code}
> Ant-style variables can throw exception when evaluated for their value
> --
>
> Key: JEXL-323
> URL: https://issues.apache.org/jira/browse/JEXL-323
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: David Costanzo
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> When try to evaluate an expression that is the name of a variable and the
> value is null, I get the value null. This is good. However, when I do the
> same thing with an ant-style variable name, a JexlException$Variable is
> thrown claiming that the variable is null. I think this is a bug because I
> would expect all variables to behave the same, regardless of their name.
> The reason for this behavior is evident in Interpreter.visit() and
> InterpreterBase.unsolvableVariable(). There is already special-case logic to
> detect when an ant variable is null versus when it's undefined, and this
> information is given to unsolvableVariable(), but it still throws an
> exception.
>
> {code:java}
> if (object == null && !isTernaryProtected(node)) {
> if (antish && ant != null) {
> // V--- NOTE: context.has() returns true, so undefined is false
> boolean undefined = !(context.has(ant.toString()) ||
> isLocalVariable(node, 0));
> // variable unknown in context and not a local
> return unsolvableVariable(node, ant.toString(), undefined); //
> <-- still throws exception
> } else if (!pty) {
> return unsolvableProperty(node, ".", null);
> }
> }
> {code}
> In in unsolvableVariable():
>
> {code:java}
> protected Object unsolvableVariable(JexlNode node, String var, boolean undef)
> {
> // V-- NOTE: both my engine and arithmetic are strict, so this evaluates
> to true
> if (isStrictEngine() && (undef || arithmetic.isStrict())) {
> throw new JexlException.Variable(node, var, undef);
> } else if (logger.isDebugEnabled()) {
> logger.debug(JexlException.variableError(node, var, undef));
> }
> return null;
> }
> {code}
>
>
> h3. Steps to Reproduce:
>
> {code:java}
> @Test
> public void testNullAntVariable() throws IOException {
> // Create or retrieve an engine
> JexlEngine jexl = new JexlBuilder().create();
> // on recent code: JexlEngine jexl = new
> JexlBuilder().safe(false).create();
> // Populate to identical global variables
> JexlContext jc = new MapContext();
> jc.set("NormalVariable", null);
> jc.set("ant.variable", null);
> // Evaluate the value of the normal variable
> JexlExpression expression1 = jexl.createExpression("NormalVariable");
> Object o1 = expression1.evaluate(jc);
> Assert.assertEquals(null, o1);
> // Evaluate the value of the ant-style variable
> JexlExpression expression2 = jexl.createExpression("ant.variable");
> Object o2 = expression2.evaluate(jc); // <-- BUG: throws exception
> instead of returning null
> Assert.assertEquals(null, o2);
> }
> {code}
>
>
> h3. What Happens:
> "expression2.evaluate(jc)" throws an JexlException$Variable exception with
> text like "variable 'ant.variable' is null".
> h3. Expected Result:
> expression2.evaluate(jc) returns the value of 'ant.variable', which is null.
> h3.
> Note:
> This was found on JEXL 3.1, the latest official release. I reproduced it on a
> snapshot of JEXL 3.2 built from github source, but had to disable "safe".
> h3.
> Impact:
> My organization uses JEXL to build datasets for clinical trials. In our
> domain, it's very common to have an expression that is simply the name of a
> variable whose value is desired. In our domain, we want any sloppy
> expressions to be a hard error, so we we use strict engines and will use
> "safe=false" when we update to JEXL 3.2. In our domain, "null" has a specific
> meaning (it means "missing"). A
[jira] [Created] (JEXL-325) Potential race-condition in NumberParser.toString()
Dmitri Blinov created JEXL-325:
--
Summary: Potential race-condition in NumberParser.toString()
Key: JEXL-325
URL: https://issues.apache.org/jira/browse/JEXL-325
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
To format {{BigDecimal}} values the current implementation uses *static*
instance of {{DecimalFormat}} class without synchronization, whereas according
to Java doc Decimal formats are not synchronized and must be synchronized
externally. There is also a dead branch on BigDecimal check. The suggestion is
to change NumberParser.to String() to something as follows:
{code}
@Override
public String toString() {
if (literal == null || clazz == null ||
Double.isNaN(literal.doubleValue())) {
return "NaN";
}
if (BigDecimal.class.equals(clazz)) {
synchronized (BIGDF) {
return BIGDF.format(literal);
}
}
StringBuilder strb = new StringBuilder(literal.toString());
if (Float.class.equals(clazz)) {
strb.append('f');
} else if (Double.class.equals(clazz)) {
strb.append('d');
} else if (BigInteger.class.equals(clazz)) {
strb.append('h');
} else if (Long.class.equals(clazz)) {
strb.append('l');
}
return strb.toString();
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020834#comment-17020834
]
Dmitri Blinov edited comment on JEXL-307 at 1/23/20 9:07 AM:
-
And one more thing... hoisted variables are not resolved in nested blocks -
_*variable 'x' is undefined*_
{code:java}
@Test
public void testHoisted() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("var x = 10; var a = function(var
b) {for (var q : 1 ..10) {return x + b}}; a(32)");
JexlContext jc = new MapContext();
Object result = script.execute(null);
Assert.assertEquals(result, 42);
}
{code}
If the lexical feature is switched off everything works OK.
The problem stems from the fact that hoisted variables *may* change their frame
pointer index (aka symbol) between frames. So when we check identifier inside
{{JexlParser.checkVariable()}} we can not simply check for all lexical units
for the identifier to be declared by its *symbol*. We either need to keep track
of Frame-LexicalUnit relation when we traverse the lexical stack, or to check
for variable by identifier *name* inside LexicalUnit.
PS. Technically, what we call a *hoisted* variable in JEXL is a *captured*
variable. Maybe its a good point to rebrand this term to make things clear not
only from implementation point, but from its definition?
was (Author: dmitri_blinov):
And one more thing... hoisted variables are not resolved in nested blocks -
_*variable 'x' is undefined*_
{code:java}
@Test
public void testHoisted() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("var x = 10; var a = function(var
b) {for (var q : 1 ..10) {return x + b}}; a(32)");
JexlContext jc = new MapContext();
Object result = script.execute(null);
Assert.assertEquals(result, 42);
}
{code}
If the lexical feature is switched off everything works OK.
The problem stems from the fact that hoisted variables *may* change their frame
pointer index (aka symbol) between frames. So when we check identifier inside
{{JexlParser.checkVariable()}} we can not simply check for all lexical units
for the identifier to be declared by its *symbol*. We either need to keep track
of Frame-LexicalUnit relation when we traverse the lexical stack, or to check
for variable by identifier *name* inside LexicalUnit.
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020834#comment-17020834
]
Dmitri Blinov edited comment on JEXL-307 at 1/23/20 7:26 AM:
-
And one more thing... hoisted variables are not resolved in nested blocks -
_*variable 'x' is undefined*_
{code:java}
@Test
public void testHoisted() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("var x = 10; var a = function(var
b) {for (var q : 1 ..10) {return x + b}}; a(32)");
JexlContext jc = new MapContext();
Object result = script.execute(null);
Assert.assertEquals(result, 42);
}
{code}
If the lexical feature is switched off everything works OK.
The problem stems from the fact that hoisted variables *may* change their frame
pointer index (aka symbol) between frames. So when we check identifier inside
{{JexlParser.checkVariable()}} we can not simply check for all lexical units
for the identifier to be declared by its *symbol*. We either need to keep track
of Frame-LexicalUnit relation when we traverse the lexical stack, or to check
for variable by identifier *name* inside LexicalUnit.
was (Author: dmitri_blinov):
And one more thing... hoisted variables are not resolved in nested blocks -
_*variable 'x' is undefined*_
{code:java}
@Test
public void testHoisted() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("var x = 10; var a = function(var
b) {for (var q : 1 ..10) {return x + b}}; a(32)");
JexlContext jc = new MapContext();
Object result = script.execute(null);
Assert.assertEquals(result, 42);
}
{code}
If the lexical feature is switched off everything works OK.
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020834#comment-17020834
]
Dmitri Blinov commented on JEXL-307:
And one more thing... hoisted variables are not resolved in nested blocks -
_*variable 'x' is undefined*_
{code:java}
@Test
public void testHoisted() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("var x = 10; var a = function(var
b) {for (var q : 1 ..10) {return x + b}}; a(32)");
JexlContext jc = new MapContext();
Object result = script.execute(null);
Assert.assertEquals(result, 42);
}
{code}
If the lexical feature is switched off everything works OK.
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019468#comment-17019468
]
Dmitri Blinov commented on JEXL-307:
It seems I have found a nasty regression - the code below fails with _*x:
variable is already defined*_
{code:java}
@Test
public void testNamed() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("var i = function(x, y, z)
{return x + y + z}; i(20,20,2)");
JexlContext jc = new MapContext();
Object result = script.execute(jc);
Assert.assertEquals(result, 42);
}
{code}
If the lexical feature is switched *off* everything works OK.
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JEXL-321) Empty do-while loop is broken
Dmitri Blinov created JEXL-321:
--
Summary: Empty do-while loop is broken
Key: JEXL-321
URL: https://issues.apache.org/jira/browse/JEXL-321
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
The following test case with AIOOB.
{code:java}
@Test
public void testEmptyBody() throws Exception {
JexlScript e = JEXL.createScript("var i = 0; do ; while((i+=1) < 10);
i");
JexlContext jc = new MapContext();
Object o = e.execute(jc);
Assert.assertEquals(10, o);
} {code}
The suggestion is to change interpreter as follows
{code}
@Override
protected Object visit(ASTDoWhileStatement node, Object data) {
Object result = null;
/* last objectNode is the expression */
Node expressionNode = node.jjtGetChild(node.jjtGetNumChildren()-1);
do {
cancelCheck(node);
if (node.jjtGetNumChildren() > 1) {
try {
// execute statement
result = node.jjtGetChild(0).jjtAccept(this, data);
} catch (JexlException.Break stmtBreak) {
break;
} catch (JexlException.Continue stmtContinue) {
//continue;
}
}
} while (arithmetic.toBoolean(expressionNode.jjtAccept(this, data)));
return result;
}
{code} and Debugger as follows
{code}
@Override
protected Object visit(ASTDoWhileStatement node, Object data) {
int num = node.jjtGetNumChildren();
builder.append("do ");
if (num > 1) {
acceptStatement(node.jjtGetChild(0), data);
} else {
builder.append(" ; ");
}
builder.append(" while (");
accept(node.jjtGetChild(num - 1), data);
builder.append(")");
return data;
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JEXL-318) Annotation processing may fail in lexical mode
Dmitri Blinov created JEXL-318:
--
Summary: Annotation processing may fail in lexical mode
Key: JEXL-318
URL: https://issues.apache.org/jira/browse/JEXL-318
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
I fave found that the annotation processing under certain conditions may lead
to NPE
{code:java}
public static class OptAnnotationContext extends JexlEvalContext implements
JexlContext.AnnotationProcessor {
@Override
public Object processAnnotation(String name, Object[] args,
Callable statement) throws Exception {
JexlOptions options = this.getEngineOptions();
// transient side effect for strict
if ("scale".equals(name)) {
int scale = options.getMathScale();
int newScale = (Integer) args[0];
options.setMathScale(newScale);
try {
return statement.call();
} finally {
options.setMathScale(scale);
}
}
return statement.call();
}
}
@Test
public void testAnnotation() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("@scale(13) @test var i = 42");
JexlContext jc = new OptAnnotationContext();
Object result = script.execute(jc);
Assert.assertEquals(result, 42);
}
{code}
This is because new instance of Interpeter is created to process annotation
under certain conditions, and this new instance does not inherit the current
lexical block. Furthermore, the constructor of InterperterBase
{{InterpreterBase(InterpreterBase ii, JexlArithmetic jexla)}} now silently
ignores JexlArithmetic passed to it, which is possibly another bug.
As a suggestion, can we refactor the code to simply make JexlArithmetic non
final in InterpreterBase? There would be no need to create new instance of
Interpeter and complicate code with sync-state code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-259) Shorter ant-ish variables prevent longer ant-ish variables from being resolved properly
[
https://issues.apache.org/jira/browse/JEXL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003126#comment-17003126
]
Dmitri Blinov commented on JEXL-259:
I ditched the ant-ish variables and have managed to write cascade resolver that
resolves one part after another. That was not a generic solution for all cases,
but was just enough for my use-case.
> Shorter ant-ish variables prevent longer ant-ish variables from being
> resolved properly
> ---
>
> Key: JEXL-259
> URL: https://issues.apache.org/jira/browse/JEXL-259
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
> Fix For: 3.1
>
>
> The following script is evaluated successfully
> {code}
> a.b.c = 2; a.b = 1; return a.b
> {code}
> While the following scripts are terminated with error {{unsolvable property
> 'c'}}
> {code}
> a.b = 1; a.b.c = 2; return a.b
> {code}
> {code}
> a.b.c = 2; a.b = 1; return a.b.c
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16993265#comment-16993265
]
Dmitri Blinov commented on JEXL-307:
Options are OK. The test case to illustrate the problem is this
{code:java}
@Test
public void testLexical6a1() throws Exception {
String str = "i = 0; { var i = 32; }; i";
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript e = jexl.createScript(str);
JexlContext ctxt = new MapContext();
Object o = e.execute(ctxt);
Assert.assertEquals(0, o);
}{code}
The above test case fails with - variable is not defined. I understand the
intention was good - to check for variables that are out of scope. But in
practice it has become a severe restriction, with no way to disable.
Compare it with existing test case, which is OK and is an example of what I
wish we could somehow achieve with lexical *feature* enabled.
{code:java}
@Test
public void testLexical6a() throws Exception {
String str = "i = 0; { var i = 32; }; i";
JexlEngine jexl = new JexlBuilder().strict(true).lexical(true).create();
JexlScript e = jexl.createScript(str);
JexlContext ctxt = new MapContext();
Object o = e.execute(ctxt);
Assert.assertEquals(0, o);
} {code}
I'm not in favor of creating as much additional features as possible. If we
could just *align* behaviour of lexical feature with that of lexical option,
there would be no need for a new feature to disable that variable check.
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989652#comment-16989652
]
Dmitri Blinov commented on JEXL-307:
Now that everything works as expected I wonder whether it is possible to
decouple undeclared variable check in lexical mode from lexical mode itself.
Can we make undeclared variable check a separate JEXL feature? The problem is
that now, when lexical feature is enabled, once the variable with the name
'foo' has been declared, there is no way to access context variable with the
same name, which requires to completely rewrite and check whole script - this
addes up additional migration pains.
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986701#comment-16986701
]
Dmitri Blinov commented on JEXL-307:
Maybe I do not fully understand what the lexical feature is all about, but from
the previous test case I've learned the idea was to control the access to
undeclared local variables. If I'm right, then the following test case should
also pass, but it doesn't.
{code:java}
@Test
public void testForVariable() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
try {
JexlScript script = jexl.createScript("for(var x : 1..3) { var c =
0}; return x");
Assert.fail("Should not have been parsed");
} catch (Exception ex) {
// OK
}
}
{code}
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985015#comment-16985015
]
Dmitri Blinov commented on JEXL-307:
The following test fails with *undefined variable x* in most inner block;
{code:java}
@Test
public void testInnerAccess() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
JexlScript script = jexl.createScript("var x = 32; (()->{ for(var x :
null) { var c = 0; {return x; }} })();");
}
{code}
Interestingly, the next test case passes successfully
{code:java}
@Test
public void testInnerAccess() throws Exception {
JexlEngine jexl = new JexlBuilder().strict(true).lexical(true).create();
JexlScript script = jexl.createScript("var x = 32; (()->{ for(var x :
null) { var c = 0; {return x; }} })();");
}
{code}
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
