[jira] [Commented] (JEXL-342) Support for Java Optional.

["Dmitri Blinov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289743#comment-17289743 ] 

Dmitri Blinov commented on JEXL-342:
------------------------------------

I've made some fiddling with new features for JEXL the other day, but many of them were not accepted at that time even with Jira tasks and PRs on github, so generally this is not an easy task, it's kind of making an omelette without breaking eggs job. Nevertheless the desire to get something done, to fill the gaps between JEXL and well-accepted modern ideas in other languages (Java 8 itself to start with) brought me to idea to get a fork, so anyone interesting in evolving JEXL could look at ([link to repository|https://github.com/dmitri-blinov/commons-jexl]). I'd love to have all or any of those features to be part of the upstream one day, though as I have said before, I fully understand that not everyone would be happy to get the eggs broken. But the progress is inevitable, and for the long run choice is tough - either JEXL will evolve or stall as a project. The solution in my opinion is well known and would be to have a major version bump for some modern experimental stuff and stable version for current implementation.

> Support for Java Optional.
> --------------------------
>
>                 Key: JEXL-342
>                 URL: https://issues.apache.org/jira/browse/JEXL-342
>             Project: Commons JEXL
>          Issue Type: New Feature
>    Affects Versions: 3.1
>            Reporter: Garret Wilson
>            Priority: Major
>
> Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can this this easily be added as some sort of plugin, or better yet can it be added to the library?
> h3. {{Optional}} Traversal
> I need to create an API that works well for application developers as for those using templates with JEXL expressions. Let's say that the {{Bar}} class has a {{Bar.getName()}}. And the {{Foo}} class has this method:
> {code:java}
> Optional<Bar> 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<Bar> 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)