[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-366) Fail to evaluate string and number comparison
[
https://issues.apache.org/jira/browse/JEXL-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532645#comment-17532645
]
Hussachai Puripunpinyo edited comment on JEXL-366 at 5/6/22 5:02 AM:
-
[~henrib] Can you shed some light on why you want to avoid using BigDecimal?
Your change has a flaw when it fallbacks to String comparison. The following
method truncates the decimal point.
{code:java}
private long comparableLong(Object arg) throws NumberFormatException {
if (arg instanceof String) {
String s = (String) arg;
return s.isEmpty()? 0 :(long) Double.parseDouble((String) arg);
} else {
return toLong(arg);
}
} {code}
There is a bug when one operand is a string with decimal and another one is a
numerable.
For example "1.01" == 1 This will return true for your change when it should
not.
was (Author: hussachai):
[~henrib] Can you shed some light on why you want to avoid using BigDecimal?
Your change has a flaw when it fallbacks to String comparison. The following
method truncate the decimal point.
{code:java}
private long comparableLong(Object arg) throws NumberFormatException {
if (arg instanceof String) {
String s = (String) arg;
return s.isEmpty()? 0 :(long) Double.parseDouble((String) arg);
} else {
return toLong(arg);
}
} {code}
There is a bug when one operand is a string with decimal and another one is a
numerable.
For example "1.01" == 1 This will return true for your change when it should
not.
> Fail to evaluate string and number comparison
> -
>
> Key: JEXL-366
> URL: https://issues.apache.org/jira/browse/JEXL-366
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> The comparison logic doesn't cover the case when one operand is a string and
> another operand is a numerable type (int, short, long,..).
> The expected result for '1.0' == 1 should be true but it fails because the
> string comparison check is after the numerable type check. JEXL tries to
> parse '1.0' using toLong function and it fails with this error message `For
> input string: "1.0"`
> Moving a string comparison up before other number type checks will not cover
> some corner cases such as
> '1.00' == 1.0 // String comparison will yield false but it obviously doesn't
> make sense.
> The proposed change is to add the following code to handle the corner case
> when one operand is string and another operand is numerable. To cover this
> corner case, we can apply toBigDecimal to both *lhs* and *rhs* since it
> should cover any arbitrary number in a string form, and it handles other
> number types well.
> {code:java}
> if (isNumberable(left) || isNumberable(right)) {
> if (left instanceof String || right instanceof String) {
> final BigDecimal l = toBigDecimal(left);
> final BigDecimal r = toBigDecimal(right);
> return l.compareTo(r);
> } else {
> // this code block remains the same
> }
> return 0;
> } {code}
> JEXL syntax is very similar to ECMA script except a few small set that are
> not the same. So, I think following the ECMA spec for this comparison check
> makes sense.
> The following code is JavaScript and it can be used in the JEXL test to make
> sure that the behavior of comparison are the same.
> Note that '1.0' == 1 yields true
> {code:java}
> function assert(condition, source) {
> if (!condition) {
> throw `Assertion failed for ${source}`;
> }
> }
> // Basic compare
> let exprs = [
> "1 == 1", true,
> "1 != 1", false,
> "1 != 2", true,
> "1 > 2", false,
> "1 >= 2", false,
> "1 < 2", true,
> "1 <= 2", true,
> // Int <-> Float Coercion
> "1.0 == 1", true,
> "1 == 1.0", true,
> "1.1 != 1", true,
> "1.1 < 2", true,
> // numbers and strings
> "'1' == 1", true,
> "'' == 0", true, // empty string is coerced to zero (ECMA compliance)
> "1.0 >= '1'", true,
> "1.0 > '1'", false
> ];for (e = 0; e < exprs.length; e += 2) {
> let stext = exprs[e];
> let expected = exprs[e + 1];
> assert(eval(stext) == expected, stext);
>
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-366) Fail to evaluate string and number comparison
[
https://issues.apache.org/jira/browse/JEXL-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532645#comment-17532645
]
Hussachai Puripunpinyo commented on JEXL-366:
-
[~henrib] Can you shed some light on why you want to avoid using BigDecimal?
Your change has a flaw when it fallbacks to String comparison. The following
method truncate the decimal point.
{code:java}
private long comparableLong(Object arg) throws NumberFormatException {
if (arg instanceof String) {
String s = (String) arg;
return s.isEmpty()? 0 :(long) Double.parseDouble((String) arg);
} else {
return toLong(arg);
}
} {code}
There is a bug when one operand is a string with decimal and another one is a
numerable.
For example "1.01" == 1 This will return true for your change when it should
not.
> Fail to evaluate string and number comparison
> -
>
> Key: JEXL-366
> URL: https://issues.apache.org/jira/browse/JEXL-366
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> The comparison logic doesn't cover the case when one operand is a string and
> another operand is a numerable type (int, short, long,..).
> The expected result for '1.0' == 1 should be true but it fails because the
> string comparison check is after the numerable type check. JEXL tries to
> parse '1.0' using toLong function and it fails with this error message `For
> input string: "1.0"`
> Moving a string comparison up before other number type checks will not cover
> some corner cases such as
> '1.00' == 1.0 // String comparison will yield false but it obviously doesn't
> make sense.
> The proposed change is to add the following code to handle the corner case
> when one operand is string and another operand is numerable. To cover this
> corner case, we can apply toBigDecimal to both *lhs* and *rhs* since it
> should cover any arbitrary number in a string form, and it handles other
> number types well.
> {code:java}
> if (isNumberable(left) || isNumberable(right)) {
> if (left instanceof String || right instanceof String) {
> final BigDecimal l = toBigDecimal(left);
> final BigDecimal r = toBigDecimal(right);
> return l.compareTo(r);
> } else {
> // this code block remains the same
> }
> return 0;
> } {code}
> JEXL syntax is very similar to ECMA script except a few small set that are
> not the same. So, I think following the ECMA spec for this comparison check
> makes sense.
> The following code is JavaScript and it can be used in the JEXL test to make
> sure that the behavior of comparison are the same.
> Note that '1.0' == 1 yields true
> {code:java}
> function assert(condition, source) {
> if (!condition) {
> throw `Assertion failed for ${source}`;
> }
> }
> // Basic compare
> let exprs = [
> "1 == 1", true,
> "1 != 1", false,
> "1 != 2", true,
> "1 > 2", false,
> "1 >= 2", false,
> "1 < 2", true,
> "1 <= 2", true,
> // Int <-> Float Coercion
> "1.0 == 1", true,
> "1 == 1.0", true,
> "1.1 != 1", true,
> "1.1 < 2", true,
> // numbers and strings
> "'1' == 1", true,
> "'' == 0", true, // empty string is coerced to zero (ECMA compliance)
> "1.0 >= '1'", true,
> "1.0 > '1'", false
> ];for (e = 0; e < exprs.length; e += 2) {
> let stext = exprs[e];
> let expected = exprs[e + 1];
> assert(eval(stext) == expected, stext);
>
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-compress] dependabot[bot] opened a new pull request, #290: Bump maven-bundle-plugin from 5.1.4 to 5.1.5
dependabot[bot] opened a new pull request, #290: URL: https://github.com/apache/commons-compress/pull/290 Bumps maven-bundle-plugin from 5.1.4 to 5.1.5. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] dependabot[bot] opened a new pull request, #190: Bump checkstyle from 9.2.1 to 10.2
dependabot[bot] opened a new pull request, #190: URL: https://github.com/apache/commons-dbcp/pull/190 Bumps [checkstyle](https://github.com/checkstyle/checkstyle) from 9.2.1 to 10.2. Release notes Sourced from https://github.com/checkstyle/checkstyle/releases;>checkstyle's releases. checkstyle-10.2 https://checkstyle.org/releasenotes.html#Release_10.2;>https://checkstyle.org/releasenotes.html#Release_10.2 checkstyle-10.1 https://checkstyle.org/releasenotes.html#Release_10.1;>https://checkstyle.org/releasenotes.html#Release_10.1 checkstyle-10.0 https://checkstyle.org/releasenotes.html#Release_10.0;>https://checkstyle.org/releasenotes.html#Release_10.0 checkstyle-9.3 https://checkstyle.org/releasenotes.html#Release_9.3;>https://checkstyle.org/releasenotes.html#Release_9.3 Commits https://github.com/checkstyle/checkstyle/commit/0678fc609ec1889e3534940aa9d094887a4af2f3;>0678fc6 [maven-release-plugin] prepare release checkstyle-10.2 https://github.com/checkstyle/checkstyle/commit/acf70b4d7e8e4423579f02bf88d9773ba9574a77;>acf70b4 doc: release notes for 10.2 https://github.com/checkstyle/checkstyle/commit/591b41028cecc786ea94556791a8e53a99defb4c;>591b410 Issue https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/4845;>#4845: remove dependency on netbuddy from test inputs https://github.com/checkstyle/checkstyle/commit/0fda5157d34980c229090931af2a1a1ce74e87a9;>0fda515 dependency: bump maven-antrun-plugin from 3.0.0 to 3.1.0 https://github.com/checkstyle/checkstyle/commit/7f5fcc814f63a590d24b34a3e6289facfbffc264;>7f5fcc8 supplemental: Modify pitest.sh to support unstable mutations list https://github.com/checkstyle/checkstyle/commit/0ab05c948d302dde4f3e4144e97af30a2613900a;>0ab05c9 Issue https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/11528;>#11528: Kill surviving mutation in EqualsAvoidNullCheck https://github.com/checkstyle/checkstyle/commit/c2abb6fb4cef7c4d3e565bd05d061841fc86db50;>c2abb6f minor: fix link (link-check-plugin) https://github.com/checkstyle/checkstyle/commit/4a7e6fa6b7eeb0658d09c64bc9f390f24c3ab10b;>4a7e6fa dependency: bump nexus-staging-maven-plugin from 1.6.12 to 1.6.13 https://github.com/checkstyle/checkstyle/commit/8035e76a5ba81f4841519d0d3ceb9e7a4f913506;>8035e76 dependency: bump mockito-inline from 4.5.0 to 4.5.1 https://github.com/checkstyle/checkstyle/commit/d00939d8400537a7eecc56e7ec1fdaf3f0574333;>d00939d dependency: bump maven-site-plugin from 3.11.0 to 3.12.0 Additional commits viewable in https://github.com/checkstyle/checkstyle/compare/checkstyle-9.2.1...checkstyle-10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] dependabot[bot] opened a new pull request, #189: Bump spotbugs from 4.6.0 to 4.7.0
dependabot[bot] opened a new pull request, #189: URL: https://github.com/apache/commons-dbcp/pull/189 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.6.0 to 4.7.0. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases;>spotbugs's releases. SpotBugs 4.7.0 CHANGELOG Changed Updated documentation by adding parenthesis () to the negative odd check message (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1995;>#1995) https://github.com/axkr;>@axkr Let the Plugin class implement AutoCloseable so we can release the .jar file (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2024;>#2024) https://github.com/gtoison;>@gtoison Fixed Fixed reports to truncate existing files before writing new content (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1950;>#1950) https://github.com/sdati;>@sdati Fixed traversal of nested archives governed by -nested:true (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1930;>#1930) https://github.com/Vogel612;>@Vogel612 Warnings of deprecated System::setSecurityManager calls on Java 17 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1983;>#1983) https://github.com/wborn;>@wborn Fixed false positive SSD bug for locking on java.lang.Class objects (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1978;>#1978) https://github.com/jpschewe;>@jpschewe FindReturnRef throws an IllegalArgumentException unexpectedly (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2019;>#2019) https://github.com/KengoTODA;>@KengoTODA Bumped Saxon-HE from 10.6 to 11.3 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1955;>#1955, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1999;>#1999) Bump ObjectWeb ASM from 9.2 to 9.3 supporting JDK 19 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/2004;>#2004) Added New detector ThrowingExceptions and introduced new bug types https://github.com/oroszbd;>@oroszbd THROWS_METHOD_THROWS_RUNTIMEEXCEPTION is reported in case of a method throwing RuntimeException, THROWS_METHOD_THROWS_CLAUSE_BASIC_EXCEPTION is reported when a method has Exception in its throws clause and THROWS_METHOD_THROWS_CLAUSE_THROWABLE is reported when a method has Throwable in its throws clause (See https://wiki.sei.cmu.edu/confluence/display/java/ERR07-J.+Do+not+throw+RuntimeException%2C+Exception%2C+or+Throwable;>SEI CERT ERR07-J) New rule PERM_SUPER_NOT_CALLED_IN_GETPERMISSIONS to warn for custom class loaders who do not call their superclasses' getPermissions() in their getPermissions() method. This rule based on the SEI CERT rule SEC07-J Call the superclass's getPermissions() method when writing a custom class loader. (https://wiki.sei.cmu.edu/confluence/display/java/SEC07-J.+Call+the+superclass%27s+getPermissions%28%29+method+when+writing+a+custom+class+loader;>#SEC07-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New rule USC_POTENTIAL_SECURITY_CHECK_BASED_ON_UNTRUSTED_SOURCE to detect cases where a non-final method of a non-final class is called from public methods of public classes and then the same method is called on the same object inside a doPrivileged block. Since the called method may have been overridden to behave differently on the first and second invocations this is a possible security check based on an unreliable source. This rule is based on SEC02-J. Do not base security checks on untrusted sources. (https://wiki.sei.cmu.edu/confluence/display/java/SEC02-J.+Do+not+base+security+checks+on+untrusted+sources;>#SEC02-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New detector DontUseFloatsAsLoopCounters to detect usage of floating-point variables as loop counters (FL_FLOATS_AS_LOOP_COUNTERS), according to SEI CERT rules https://wiki.sei.cmu.edu/confluence/display/java/NUM09-J.+Do+not+use+floating-point+variables+as+loop+counters;>NUM09-J. Do not use floating-point variables as loop counters https://github.com/adrianturtoczki;>@adrianturtoczki New test detector ViewCFG to visualize the control-flow graph for SpotBugs developers https://github.com/baloghadamsoftware;>@baloghadamsoftware CHECKSUM file checksum (sha256) spotbugs-4.7.0-javadoc.jar 43745221e8fdf50fa2f89d659034523dd58da3d10223de6e0c91704c07e025a0 spotbugs-4.7.0-sources.jar 6e90f856826b48a3031e2cb903534b4fdb494759863ea14e8df93c9cf15a272c spotbugs-4.7.0.tgz 8c871e279c7d9b1933158db6355b8ac817a84fd724b88b1e393e3abcf6874910 spotbugs-4.7.0.zip 9ee793b0f3f78901089211dfa67b8603e38fd1abd64eac09d2590df506cfedf5 spotbugs-annotations-4.7.0-javadoc.jar 76a9a7d45590494a220840d173809b2fe0ec50e554435dd9b28de9312cc6a34a spotbugs-annotations-4.7.0-sources.jar
[GitHub] [commons-compress] darkma773r commented on pull request #289: Fix TarFileTest
darkma773r commented on PR #289: URL: https://github.com/apache/commons-compress/pull/289#issuecomment-1119236042 @garydgregory, this fixes `TarFileTest` on Linux but it's not clear to me if this is the correct fix or if a deeper issue needs to be resolved. The test started failing with the PR for COMPRESS-612 and the extended logic for detecting the XSTAR format [here](https://github.com/apache/commons-compress/blob/afa14ea0fe5c65ab923080ccded72678979563fa/src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java#L741). The logic previously evaluated the test tar files as being in POSIX_FORMAT and so appended the '/' character to the end of directory names. It now evaluates to XSTAR and so does not append the '/' character. In order to make the test pass, I changed the requested entry format in the test from BIGNUMBER_STAR to BIGNUMBER_POSIX. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] darkma773r opened a new pull request, #289: Fix TarFileTest
darkma773r opened a new pull request, #289: URL: https://github.com/apache/commons-compress/pull/289 fix TarFileTest.testDirectoryWithLongNameEndsWithSlash -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] darkma773r closed pull request #176: Bump spring.version from 5.3.18 to 5.3.19
darkma773r closed pull request #176: Bump spring.version from 5.3.18 to 5.3.19 URL: https://github.com/apache/commons-configuration/pull/176 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] dependabot[bot] commented on pull request #176: Bump spring.version from 5.3.18 to 5.3.19
dependabot[bot] commented on PR #176: URL: https://github.com/apache/commons-configuration/pull/176#issuecomment-1119191645 OK, I won't notify you again about this release, but will get in touch when a new version is available. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] darkma773r closed pull request #177: Bump commons-parent from 52 to 53
darkma773r closed pull request #177: Bump commons-parent from 52 to 53 URL: https://github.com/apache/commons-configuration/pull/177 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] dependabot[bot] commented on pull request #177: Bump commons-parent from 52 to 53
dependabot[bot] commented on PR #177: URL: https://github.com/apache/commons-configuration/pull/177#issuecomment-1119191396 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (IO-768) Add reserved Windows file names CONIN$ and CONOUT$ to FileSystem
[
https://issues.apache.org/jira/browse/IO-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-768.
Fix Version/s: 2.12.0
Resolution: Fixed
> Add reserved Windows file names CONIN$ and CONOUT$ to FileSystem
>
>
> Key: IO-768
> URL: https://issues.apache.org/jira/browse/IO-768
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.11.0
>Reporter: Marcono1234
>Priority: Minor
> Fix For: 2.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The file names {{CONIN$}} and {{CONOUT$}} are also reserved on Windows, see
> https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea#consoles.
> Example code:
> {code}
> jshell> Files.readString(Path.of("CONIN$"))
> | Exception java.io.IOException: Incorrect function
> ...
> {code}
> It would be good to add them to {{org.apache.commons.io.FileSystem}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-io] garydgregory merged pull request #355: IO-768: Add reserved Windows file names CONIN$ and CONOUT$ to FileSystem
garydgregory merged PR #355: URL: https://github.com/apache/commons-io/pull/355 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-768) Add reserved Windows file names CONIN$ and CONOUT$ to FileSystem
[
https://issues.apache.org/jira/browse/IO-768?focusedWorklogId=766978=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-766978
]
ASF GitHub Bot logged work on IO-768:
-
Author: ASF GitHub Bot
Created on: 06/May/22 01:03
Start Date: 06/May/22 01:03
Worklog Time Spent: 10m
Work Description: garydgregory merged PR #355:
URL: https://github.com/apache/commons-io/pull/355
Issue Time Tracking
---
Worklog Id: (was: 766978)
Time Spent: 0.5h (was: 20m)
> Add reserved Windows file names CONIN$ and CONOUT$ to FileSystem
>
>
> Key: IO-768
> URL: https://issues.apache.org/jira/browse/IO-768
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.11.0
>Reporter: Marcono1234
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The file names {{CONIN$}} and {{CONOUT$}} are also reserved on Windows, see
> https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea#consoles.
> Example code:
> {code}
> jshell> Files.readString(Path.of("CONIN$"))
> | Exception java.io.IOException: Incorrect function
> ...
> {code}
> It would be good to add them to {{org.apache.commons.io.FileSystem}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-io] garydgregory merged pull request #354: Bump maven-antrun-plugin from 3.0.0 to 3.1.0
garydgregory merged PR #354: URL: https://github.com/apache/commons-io/pull/354 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] dependabot[bot] commented on pull request #356: Bump checkstyle from 9.3 to 10.2
dependabot[bot] commented on PR #356: URL: https://github.com/apache/commons-io/pull/356#issuecomment-1119166273 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory closed pull request #356: Bump checkstyle from 9.3 to 10.2
garydgregory closed pull request #356: Bump checkstyle from 9.3 to 10.2 URL: https://github.com/apache/commons-io/pull/356 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory commented on pull request #356: Bump checkstyle from 9.3 to 10.2
garydgregory commented on PR #356: URL: https://github.com/apache/commons-io/pull/356#issuecomment-1119166260 Close: Requires Java 11. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] dependabot[bot] opened a new pull request, #356: Bump checkstyle from 9.3 to 10.2
dependabot[bot] opened a new pull request, #356: URL: https://github.com/apache/commons-io/pull/356 Bumps [checkstyle](https://github.com/checkstyle/checkstyle) from 9.3 to 10.2. Release notes Sourced from https://github.com/checkstyle/checkstyle/releases;>checkstyle's releases. checkstyle-10.2 https://checkstyle.org/releasenotes.html#Release_10.2;>https://checkstyle.org/releasenotes.html#Release_10.2 checkstyle-10.1 https://checkstyle.org/releasenotes.html#Release_10.1;>https://checkstyle.org/releasenotes.html#Release_10.1 checkstyle-10.0 https://checkstyle.org/releasenotes.html#Release_10.0;>https://checkstyle.org/releasenotes.html#Release_10.0 Commits https://github.com/checkstyle/checkstyle/commit/0678fc609ec1889e3534940aa9d094887a4af2f3;>0678fc6 [maven-release-plugin] prepare release checkstyle-10.2 https://github.com/checkstyle/checkstyle/commit/acf70b4d7e8e4423579f02bf88d9773ba9574a77;>acf70b4 doc: release notes for 10.2 https://github.com/checkstyle/checkstyle/commit/591b41028cecc786ea94556791a8e53a99defb4c;>591b410 Issue https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/4845;>#4845: remove dependency on netbuddy from test inputs https://github.com/checkstyle/checkstyle/commit/0fda5157d34980c229090931af2a1a1ce74e87a9;>0fda515 dependency: bump maven-antrun-plugin from 3.0.0 to 3.1.0 https://github.com/checkstyle/checkstyle/commit/7f5fcc814f63a590d24b34a3e6289facfbffc264;>7f5fcc8 supplemental: Modify pitest.sh to support unstable mutations list https://github.com/checkstyle/checkstyle/commit/0ab05c948d302dde4f3e4144e97af30a2613900a;>0ab05c9 Issue https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/11528;>#11528: Kill surviving mutation in EqualsAvoidNullCheck https://github.com/checkstyle/checkstyle/commit/c2abb6fb4cef7c4d3e565bd05d061841fc86db50;>c2abb6f minor: fix link (link-check-plugin) https://github.com/checkstyle/checkstyle/commit/4a7e6fa6b7eeb0658d09c64bc9f390f24c3ab10b;>4a7e6fa dependency: bump nexus-staging-maven-plugin from 1.6.12 to 1.6.13 https://github.com/checkstyle/checkstyle/commit/8035e76a5ba81f4841519d0d3ceb9e7a4f913506;>8035e76 dependency: bump mockito-inline from 4.5.0 to 4.5.1 https://github.com/checkstyle/checkstyle/commit/d00939d8400537a7eecc56e7ec1fdaf3f0574333;>d00939d dependency: bump maven-site-plugin from 3.11.0 to 3.12.0 Additional commits viewable in https://github.com/checkstyle/checkstyle/compare/checkstyle-9.3...checkstyle-10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17532548#comment-17532548
]
Henri Biestro commented on JEXL-342:
Added an OptionalArithmetic that dereferences optionals.
Commit
[fa3e3db|https://github.com/apache/commons-jexl/commit/fa3e3db789e85beb7bafcfa882af43a5ae5026c8]
> 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
> Fix For: Later
>
>
> 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.20.7#820007)
[jira] [Resolved] (JEXL-366) Fail to evaluate string and number comparison
[
https://issues.apache.org/jira/browse/JEXL-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-366.
Fix Version/s: 3.3
Assignee: Henri Biestro
Resolution: Fixed
Used a double (rather than BigDecimal) to convert string and compare to long.
Commit
[33bc10c|https://github.com/apache/commons-jexl/commit/33bc10c109403639aca7ef22dd7a883468fd6e30]
> Fail to evaluate string and number comparison
> -
>
> Key: JEXL-366
> URL: https://issues.apache.org/jira/browse/JEXL-366
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> The comparison logic doesn't cover the case when one operand is a string and
> another operand is a numerable type (int, short, long,..).
> The expected result for '1.0' == 1 should be true but it fails because the
> string comparison check is after the numerable type check. JEXL tries to
> parse '1.0' using toLong function and it fails with this error message `For
> input string: "1.0"`
> Moving a string comparison up before other number type checks will not cover
> some corner cases such as
> '1.00' == 1.0 // String comparison will yield false but it obviously doesn't
> make sense.
> The proposed change is to add the following code to handle the corner case
> when one operand is string and another operand is numerable. To cover this
> corner case, we can apply toBigDecimal to both *lhs* and *rhs* since it
> should cover any arbitrary number in a string form, and it handles other
> number types well.
> {code:java}
> if (isNumberable(left) || isNumberable(right)) {
> if (left instanceof String || right instanceof String) {
> final BigDecimal l = toBigDecimal(left);
> final BigDecimal r = toBigDecimal(right);
> return l.compareTo(r);
> } else {
> // this code block remains the same
> }
> return 0;
> } {code}
> JEXL syntax is very similar to ECMA script except a few small set that are
> not the same. So, I think following the ECMA spec for this comparison check
> makes sense.
> The following code is JavaScript and it can be used in the JEXL test to make
> sure that the behavior of comparison are the same.
> Note that '1.0' == 1 yields true
> {code:java}
> function assert(condition, source) {
> if (!condition) {
> throw `Assertion failed for ${source}`;
> }
> }
> // Basic compare
> let exprs = [
> "1 == 1", true,
> "1 != 1", false,
> "1 != 2", true,
> "1 > 2", false,
> "1 >= 2", false,
> "1 < 2", true,
> "1 <= 2", true,
> // Int <-> Float Coercion
> "1.0 == 1", true,
> "1 == 1.0", true,
> "1.1 != 1", true,
> "1.1 < 2", true,
> // numbers and strings
> "'1' == 1", true,
> "'' == 0", true, // empty string is coerced to zero (ECMA compliance)
> "1.0 >= '1'", true,
> "1.0 > '1'", false
> ];for (e = 0; e < exprs.length; e += 2) {
> let stext = exprs[e];
> let expected = exprs[e + 1];
> assert(eval(stext) == expected, stext);
>
> } {code}
>
--
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=17532536#comment-17532536 ] Henri Biestro commented on JEXL-369: You are correct, JEXL in lexical mode mimics Java's behaviour wrt variable. This is what 'let/const' would continue to enforce; avoiding redefinition of the same variable or using it beyond its scope (in my experience, these are 2 of the most common mistakes in misbehaving scripts...). > 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)
[GitHub] [commons-collections] codecov-commenter commented on pull request #307: When possible use java.lang.Objects#equals; eliminated a couple of nulls
codecov-commenter commented on PR #307: URL: https://github.com/apache/commons-collections/pull/307#issuecomment-1119011207 # [Codecov](https://codecov.io/gh/apache/commons-collections/pull/307?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#307](https://codecov.io/gh/apache/commons-collections/pull/307?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (51eb7f7) into [master](https://codecov.io/gh/apache/commons-collections/commit/1677daceab74895fdf5056c9a48aa94f9e709fb9?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (1677dac) will **increase** coverage by `0.08%`. > The diff coverage is `66.66%`. ```diff @@ Coverage Diff @@ ## master #307 +/- ## + Coverage 85.87% 85.95% +0.08% + Complexity 4676 4670 -6 Files 292 292 Lines 1346913467 -2 Branches 1955 1954 -1 + Hits 1156611576 +10 + Misses 1326 1325 -1 + Partials577 566 -11 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-collections/pull/307?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...mons/collections4/comparators/ComparatorChain.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L2NvbXBhcmF0b3JzL0NvbXBhcmF0b3JDaGFpbi5qYXZh) | `65.33% <0.00%> (ø)` | | | [...ommons/collections4/multiset/AbstractMultiSet.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L211bHRpc2V0L0Fic3RyYWN0TXVsdGlTZXQuamF2YQ==) | `43.47% <0.00%> (+0.31%)` | :arrow_up: | | [.../org/apache/commons/collections4/map/Flat3Map.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L21hcC9GbGF0M01hcC5qYXZh) | `72.76% <33.33%> (+0.19%)` | :arrow_up: | | [...llections4/comparators/TransformingComparator.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L2NvbXBhcmF0b3JzL1RyYW5zZm9ybWluZ0NvbXBhcmF0b3IuamF2YQ==) | `86.36% <50.00%> (+4.54%)` | :arrow_up: | | [...g/apache/commons/collections4/CollectionUtils.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L0NvbGxlY3Rpb25VdGlscy5qYXZh) | `94.34% <100.00%> (+0.21%)` | :arrow_up: | | [...ava/org/apache/commons/collections4/ListUtils.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L0xpc3RVdGlscy5qYXZh) | `87.30% <100.00%> (+0.68%)` | :arrow_up: | | [.../commons/collections4/functors/DefaultEquator.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L2Z1bmN0b3JzL0RlZmF1bHRFcXVhdG9yLmphdmE=) | `60.00% <100.00%> (+20.00%)` | :arrow_up: | | [...ache/commons/collections4/map/StaticBucketMap.java](https://codecov.io/gh/apache/commons-collections/pull/307/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L21hcC9TdGF0aWNCdWNrZXRNYXAuamF2YQ==) | `93.66% <100.00%> (+2.71%)` | :arrow_up: | |
[jira] [Commented] (IO-769) FileUtils.copyFileToDirectory can lead to not accessible file when preserving the filedate
[ https://issues.apache.org/jira/browse/IO-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532490#comment-17532490 ] Jérémy Carnus commented on IO-769: -- I think that the COPY_ATTRIBUTES is not needed if the code is really calling setLastModified ? Or the doc should be update to mentions that all attributes will be copied > FileUtils.copyFileToDirectory can lead to not accessible file when preserving > the filedate > -- > > Key: IO-769 > URL: https://issues.apache.org/jira/browse/IO-769 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.11.0 >Reporter: Jérémy Carnus >Priority: Major > > Hi, > The current implementation for copyFileToDirectory by default preserve the > file. > There 2 issues regarding this: > * the javadoc mentions this is done by File.setLastModified by in fact this > is done by the COPY_ATTRIBUTES options > * Under Windows, the COPY_ATTRIBUTES also copies the security attributes > (SID and permissions) and can lead to a file not beeing readable after copy > (if for example, you copie from a mount under docker or a shared folder) > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IO-769) FileUtils.copyFileToDirectory can lead to not accessible file when preserving the filedate
[ https://issues.apache.org/jira/browse/IO-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532483#comment-17532483 ] Michael Osipov commented on IO-769: --- How do you expect to fix that? > FileUtils.copyFileToDirectory can lead to not accessible file when preserving > the filedate > -- > > Key: IO-769 > URL: https://issues.apache.org/jira/browse/IO-769 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.11.0 >Reporter: Jérémy Carnus >Priority: Major > > Hi, > The current implementation for copyFileToDirectory by default preserve the > file. > There 2 issues regarding this: > * the javadoc mentions this is done by File.setLastModified by in fact this > is done by the COPY_ATTRIBUTES options > * Under Windows, the COPY_ATTRIBUTES also copies the security attributes > (SID and permissions) and can lead to a file not beeing readable after copy > (if for example, you copie from a mount under docker or a shared folder) > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IO-769) FileUtils.copyFileToDirectory can lead to not accessible file when preserving the filedate
Jeremy created IO-769: - Summary: FileUtils.copyFileToDirectory can lead to not accessible file when preserving the filedate Key: IO-769 URL: https://issues.apache.org/jira/browse/IO-769 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.11.0 Reporter: Jeremy Hi, The current implementation for copyFileToDirectory by default preserve the file. There 2 issues regarding this: * the javadoc mentions this is done by File.setLastModified by in fact this is done by the COPY_ATTRIBUTES options * Under Windows, the COPY_ATTRIBUTES also copies the security attributes (SID and permissions) and can lead to a file not beeing readable after copy (if for example, you copie from a mount under docker or a shared folder) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-imaging] dependabot[bot] opened a new pull request, #218: Bump spotbugs from 4.6.0 to 4.7.0
dependabot[bot] opened a new pull request, #218: URL: https://github.com/apache/commons-imaging/pull/218 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.6.0 to 4.7.0. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases;>spotbugs's releases. SpotBugs 4.7.0 CHANGELOG Changed Updated documentation by adding parenthesis () to the negative odd check message (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1995;>#1995) https://github.com/axkr;>@axkr Let the Plugin class implement AutoCloseable so we can release the .jar file (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2024;>#2024) https://github.com/gtoison;>@gtoison Fixed Fixed reports to truncate existing files before writing new content (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1950;>#1950) https://github.com/sdati;>@sdati Fixed traversal of nested archives governed by -nested:true (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1930;>#1930) https://github.com/Vogel612;>@Vogel612 Warnings of deprecated System::setSecurityManager calls on Java 17 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1983;>#1983) https://github.com/wborn;>@wborn Fixed false positive SSD bug for locking on java.lang.Class objects (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1978;>#1978) https://github.com/jpschewe;>@jpschewe FindReturnRef throws an IllegalArgumentException unexpectedly (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2019;>#2019) https://github.com/KengoTODA;>@KengoTODA Bumped Saxon-HE from 10.6 to 11.3 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1955;>#1955, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1999;>#1999) Bump ObjectWeb ASM from 9.2 to 9.3 supporting JDK 19 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/2004;>#2004) Added New detector ThrowingExceptions and introduced new bug types https://github.com/oroszbd;>@oroszbd THROWS_METHOD_THROWS_RUNTIMEEXCEPTION is reported in case of a method throwing RuntimeException, THROWS_METHOD_THROWS_CLAUSE_BASIC_EXCEPTION is reported when a method has Exception in its throws clause and THROWS_METHOD_THROWS_CLAUSE_THROWABLE is reported when a method has Throwable in its throws clause (See https://wiki.sei.cmu.edu/confluence/display/java/ERR07-J.+Do+not+throw+RuntimeException%2C+Exception%2C+or+Throwable;>SEI CERT ERR07-J) New rule PERM_SUPER_NOT_CALLED_IN_GETPERMISSIONS to warn for custom class loaders who do not call their superclasses' getPermissions() in their getPermissions() method. This rule based on the SEI CERT rule SEC07-J Call the superclass's getPermissions() method when writing a custom class loader. (https://wiki.sei.cmu.edu/confluence/display/java/SEC07-J.+Call+the+superclass%27s+getPermissions%28%29+method+when+writing+a+custom+class+loader;>#SEC07-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New rule USC_POTENTIAL_SECURITY_CHECK_BASED_ON_UNTRUSTED_SOURCE to detect cases where a non-final method of a non-final class is called from public methods of public classes and then the same method is called on the same object inside a doPrivileged block. Since the called method may have been overridden to behave differently on the first and second invocations this is a possible security check based on an unreliable source. This rule is based on SEC02-J. Do not base security checks on untrusted sources. (https://wiki.sei.cmu.edu/confluence/display/java/SEC02-J.+Do+not+base+security+checks+on+untrusted+sources;>#SEC02-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New detector DontUseFloatsAsLoopCounters to detect usage of floating-point variables as loop counters (FL_FLOATS_AS_LOOP_COUNTERS), according to SEI CERT rules https://wiki.sei.cmu.edu/confluence/display/java/NUM09-J.+Do+not+use+floating-point+variables+as+loop+counters;>NUM09-J. Do not use floating-point variables as loop counters https://github.com/adrianturtoczki;>@adrianturtoczki New test detector ViewCFG to visualize the control-flow graph for SpotBugs developers https://github.com/baloghadamsoftware;>@baloghadamsoftware CHECKSUM file checksum (sha256) spotbugs-4.7.0-javadoc.jar 43745221e8fdf50fa2f89d659034523dd58da3d10223de6e0c91704c07e025a0 spotbugs-4.7.0-sources.jar 6e90f856826b48a3031e2cb903534b4fdb494759863ea14e8df93c9cf15a272c spotbugs-4.7.0.tgz 8c871e279c7d9b1933158db6355b8ac817a84fd724b88b1e393e3abcf6874910 spotbugs-4.7.0.zip 9ee793b0f3f78901089211dfa67b8603e38fd1abd64eac09d2590df506cfedf5 spotbugs-annotations-4.7.0-javadoc.jar 76a9a7d45590494a220840d173809b2fe0ec50e554435dd9b28de9312cc6a34a spotbugs-annotations-4.7.0-sources.jar
[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] [Commented] (JEXL-342) Support for Java Optional.
[
https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532276#comment-17532276
]
Henri Biestro commented on JEXL-342:
[~hussachai] , you said '...changing the visibility of the functions and
classes so that we can override...'. Do you have a list of those ? May be these
changes can be incorporated in the main branch.
Regarding Optional, did you also change the Arithmetic ? Is your solution very
different from the one outlined here ?
> 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
> Fix For: Later
>
>
> 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.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=17532272#comment-17532272
]
Henri Biestro edited comment on JEXL-369 at 5/5/22 2:29 PM:
I like the idea of restricting the let/const constructs the same way other
language restrict them. (y)
The intent is to let (no pun intended) our users migrate kindly from the old
'var' semantic to the feature-enable lexical scope semantic ( JEXL-307 /
JexlFeature.lexical,lexicalShade()).
Not sure how our current lexical scope semantic differs from JS though.
was (Author: henrib):
I like the idea of restricting the let/const constructs the same way other
language restrict them. (y)
The intent is to let (no pun intended) our users migrate kindly from the old
'var' semantic to the feature-enable lexical scope semantic ( JEXL-307 /
JexlFeature.{lexical,lexicalShade}() ).
Not sure how our current lexical scope semantic differs from JS though.
> 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=17532272#comment-17532272 ] Henri Biestro edited comment on JEXL-369 at 5/5/22 2:29 PM: I like the idea of restricting the let/const constructs the same way other language restrict them. (y) The intent is to let (no pun intended) our users migrate kindly from the old 'var' semantic to the feature-enabled lexical scope semantic ( JEXL-307 / JexlFeature.lexical,lexicalShade()). Not sure how our current lexical scope semantic differs from JS though. was (Author: henrib): I like the idea of restricting the let/const constructs the same way other language restrict them. (y) The intent is to let (no pun intended) our users migrate kindly from the old 'var' semantic to the feature-enable lexical scope semantic ( JEXL-307 / JexlFeature.lexical,lexicalShade()). Not sure how our current lexical scope semantic differs from JS though. > 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=17532272#comment-17532272
]
Henri Biestro commented on JEXL-369:
I like the idea of restricting the let/const constructs the same way other
language restrict them. (y)
The intent is to let (no pun intended) our users migrate kindly from the old
'var' semantic to the feature-enable lexical scope semantic ( JEXL-307 /
JexlFeature.{lexical,lexicalShade}() ).
Not sure how our current lexical scope semantic differs from JS though.
> 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)
[GitHub] [commons-collections] stevebosman-oc opened a new pull request, #307: When possible use java.lang.Objects#equals; eliminated a couple of nulls
stevebosman-oc opened a new pull request, #307: URL: https://github.com/apache/commons-collections/pull/307 Contributed on behalf of the @opencastsoftware open source team -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jcs] tvand merged pull request #94: Bump maven-javadoc-plugin from 3.3.2 to 3.4.0
tvand merged PR #94: URL: https://github.com/apache/commons-jcs/pull/94 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jcs] tvand merged pull request #93: Bump github/codeql-action from 1 to 2
tvand merged PR #93: URL: https://github.com/apache/commons-jcs/pull/93 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
