You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Hussachai Puripunpinyo (Jira)" <ji...@apache.org> on 2022/04/26 17:08:00 UTC

[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&focusedCommentId=17528307#comment-17528307 ] 

Hussachai Puripunpinyo commented on JEXL-342:
---------------------------------------------

We forked JEXL at my company and I'd say JEXL code is very extensible. We support Java Optional and other native bindings for Scala and Kotlin including JSON types in the respective languages. We rarely touch the JEXL code to make sure that we can sync the upstream when we need to. (The only thing that is unavoidable like changing the visibility of the functions and classes so that we can override). We change the language so much until it doesn't look like JEXL :)
Anyway, I still think this is a useful feature. What about having extra package and it can be in a separate jar?

> 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<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.20.7#820007)