[jira] [Created] (CLI-307) implement testcase
jk created CLI-307: -- Summary: implement testcase Key: CLI-307 URL: https://issues.apache.org/jira/browse/CLI-307 Project: Commons CLI Issue Type: Task Reporter: jk Attachments: box.zip implement testcase -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] coveralls commented on pull request #162: Bump zstd-jni from 1.4.8-1 to 1.4.8-2
coveralls commented on pull request #162: URL: https://github.com/apache/commons-compress/pull/162#issuecomment-766601131 [](https://coveralls.io/builds/36562642) Coverage decreased (-0.02%) to 87.353% when pulling **cb3c1add0de7ea1fced3f2653c56db695a0dafdc on dependabot/maven/com.github.luben-zstd-jni-1.4.8-2** into **6fed9fb4745bd6b4506d8ddc7db23884e8bf0bdb on master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] coveralls commented on pull request #199: Bump assertj-core from 3.18.1 to 3.19.0
coveralls commented on pull request #199: URL: https://github.com/apache/commons-text/pull/199#issuecomment-766599803 [](https://coveralls.io/builds/36562549) Coverage remained the same at 98.682% when pulling **ce960045760edf9101b70d1507e22a68f2c6 on dependabot/maven/org.assertj-assertj-core-3.19.0** into **e6249a171beacf9bf0dcedff0a828c08e2f49206 on master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] coveralls commented on pull request #130: Minor Improvement:
coveralls commented on pull request #130: URL: https://github.com/apache/commons-csv/pull/130#issuecomment-766590441 [](https://coveralls.io/builds/36562306) Coverage increased (+0.002%) to 98.455% when pulling **7c748c7d56394f585a8793ee51dafe163e4dfa42 on arturobernalg:feature/minor_improvement** into **bf2f8093a49a3432be62e9fdae073e82ac78bd04 on apache:master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] dependabot[bot] opened a new pull request #162: Bump zstd-jni from 1.4.8-1 to 1.4.8-2
dependabot[bot] opened a new pull request #162: URL: https://github.com/apache/commons-compress/pull/162 Bumps [zstd-jni](https://github.com/luben/zstd-jni) from 1.4.8-1 to 1.4.8-2. Commits https://github.com/luben/zstd-jni/commit/b62515f1aca29066a6a0a13deaa96193e5137b39;>b62515f v1.4.8-2 https://github.com/luben/zstd-jni/commit/390fec0810c8fc045ce78d419eeacb9c515634c4;>390fec0 Add perf test for compressing/decompressing with RecyclingBufferBool https://github.com/luben/zstd-jni/commit/4243754d4455f1210e09812f2ca1a0817a3e4ba0;>4243754 Fix build https://github.com/luben/zstd-jni/commit/d2d556b7ecc29eecadc08f02071669887c8d4ae4;>d2d556b Don't pass -static-libgcc on platforms that use clang https://github.com/luben/zstd-jni/commit/bad9e81da230de2a7c7e5512d051ed2d3fbbf5a5;>bad9e81 Try building with static libgcc https://github.com/luben/zstd-jni/commit/5b638b865d9fea12b725cf41f82277348cf283d5;>5b638b8 CI: dump linkage information See full diff in https://github.com/luben/zstd-jni/compare/v1.4.8-1...v1.4.8-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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] dependabot[bot] opened a new pull request #199: Bump assertj-core from 3.18.1 to 3.19.0
dependabot[bot] opened a new pull request #199: URL: https://github.com/apache/commons-text/pull/199 Bumps [assertj-core](https://github.com/assertj/assertj-core) from 3.18.1 to 3.19.0. Commits https://github.com/assertj/assertj-core/commit/54e2bcae01429f43fdc135e36e4ccc2349e52da7;>54e2bca [maven-release-plugin] prepare release assertj-core-3.19.0 https://github.com/assertj/assertj-core/commit/133719e9e7a4df7e4c4e03b57c3483b3a3d5f051;>133719e Minor javadoc edit https://github.com/assertj/assertj-core/commit/fd77d821299cfdaf2d4edd746714cb22e19e4266;>fd77d82 Deprecate isXmlEqualToContentOf in favor of XML Unit https://github.com/assertj/assertj-core/commit/52c6a284bb8ce0c9063782df84f4fcc06b7c5a29;>52c6a28 Javadoc improvements https://github.com/assertj/assertj-core/commit/bb13aac7fdc73558544453e7c3f0f1db8a526619;>bb13aac Rename isEmpty/isNotEmpty to isEmptyFile/isNotEmptyFile https://github.com/assertj/assertj-core/commit/3b85988540abcf9d1d3ce6e8267b238fea03c70e;>3b85988 Bump equalsverifier from 3.5.1 to 3.5.2 (https://github-redirect.dependabot.com/assertj/assertj-core/issues/2104;>#2104) https://github.com/assertj/assertj-core/commit/67822a4b6ccb63a2639c3d78cb5fa54938c01fbd;>67822a4 Javadoc fixes and improvements https://github.com/assertj/assertj-core/commit/89292201d295dd7fbf4848b79bf0395ca26b16ba;>8929220 Prepare 3.19.0 version https://github.com/assertj/assertj-core/commit/81ba1cc4fd88f91b98e8c88666747c164d70df9e;>81ba1cc Fix javadoc warning https://github.com/assertj/assertj-core/commit/7827265a7b90db7875747857e6e4cb03fa883c51;>7827265 Remove from ShouldBeEqualByComparingOnlyGivenFields, ShouldBeEqualToIgnori... Additional commits viewable in https://github.com/assertj/assertj-core/compare/assertj-core-3.18.1...assertj-core-3.19.0;>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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-chain] arturobernalg opened a new pull request #10: Add final variable
arturobernalg opened a new pull request #10: URL: https://github.com/apache/commons-chain/pull/10 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-chain] arturobernalg opened a new pull request #9: Remove redundant initializer
arturobernalg opened a new pull request #9: URL: https://github.com/apache/commons-chain/pull/9 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-chain] arturobernalg opened a new pull request #8: Minor Improvement:
arturobernalg opened a new pull request #8: URL: https://github.com/apache/commons-chain/pull/8 * Use Collecection.addAll * Unused import * Use empty array * Unnecessary semicolon * Use Integer.valueOf 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] arturobernalg opened a new pull request #130: Minor Improvement:
arturobernalg opened a new pull request #130: URL: https://github.com/apache/commons-csv/pull/130 * System.arraycopy * Remove redundant initializer * Use empty array 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. 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=17270927#comment-17270927
]
Gary D. Gregory commented on JEXL-342:
--
Evolving JEXL is fine by me. Let's see what the community thinks. PRs on GitHub
are welcome.
> 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] [Updated] (JEXL-342) Support for Java Optional.
[
https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated JEXL-342:
---
Description:
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.
was:
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 getBar(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.
> 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
[jira] [Comment Edited] (JEXL-342) Support for Java Optional.
[
https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270914#comment-17270914
]
Garret Wilson edited comment on JEXL-342 at 1/24/21, 4:02 PM:
--
To get really wil
To get really wild, we could get the Elvis operator working, too. Using the API
in the description, I would want to have the following JEXL expression work
equivalent to the Java code
{{foo.findBar("test").map(Bar::getName).orElse("unavailable")}}:
{code}
foo.bar("test").name ?: "unavailable"
{code}
I realize that under the hood this could get pretty complicated and that the
current design of JEXL may not be amenable to this, so I didn't place it in the
main feature request description. But it does show the sort of native support
that would be nice.
In the least, recognizing the {{findXXX()}} getter pattern and turning
{{Optional<>}} to a nullable by calling {{orElse(null)}} during instance tree
traversal (and treating as you normally would treat a {{null}} return value to
short-circuit expression evaluation) should be completely doable and likely not
too much trouble.
was (Author: garretwilson):
To get really wil
To get really wild, we could get the Elvis operator working, too. Using the API
in the description, I would want to have the following JEXL expression work
equivalent to the Java code {{foo.findBar("test").map(Bar::getName).orElse("no
such bar")}}:
{code}
foo.bar("test").name ?: "no such bar"
{code}
I realize that under the hood this could get pretty complicated and that the
current design of JEXL may not be amenable to this, so I didn't place it in the
main feature request description. But it does show the sort of native support
that would be nice.
In the least, recognizing the {{findXXX()}} getter pattern and turning
{{Optional<>}} to a nullable by calling {{orElse(null)}} during instance tree
traversal (and treating as you normally would treat a {{null}} return value to
short-circuit expression evaluation) should be completely doable and likely not
too much trouble.
> 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 getBar(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] [Commented] (JEXL-342) Support for Java Optional.
[
https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270914#comment-17270914
]
Garret Wilson commented on JEXL-342:
To get really wil
To get really wild, we could get the Elvis operator working, too. Using the API
in the description, I would want to have the following JEXL expression work
equivalent to the Java code {{foo.findBar("test").map(Bar::getName).orElse("no
such bar")}}:
{code}
foo.bar("test").name ?: "no such bar"
{code}
I realize that under the hood this could get pretty complicated and that the
current design of JEXL may not be amenable to this, so I didn't place it in the
main feature request description. But it does show the sort of native support
that would be nice.
In the least, recognizing the {{findXXX()}} getter pattern and turning
{{Optional<>}} to a nullable by calling {{orElse(null)}} during instance tree
traversal (and treating as you normally would treat a {{null}} return value to
short-circuit expression evaluation) should be completely doable and likely not
too much trouble.
> 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 getBar(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] [Updated] (JEXL-342) Support for Java Optional.
[
https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated JEXL-342:
---
Description:
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 getBar(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.
was:
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").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 getBar(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.
> 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
[jira] [Created] (JEXL-342) Support for Java Optional.
Garret Wilson created JEXL-342:
--
Summary: 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
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").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 getBar(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)
