ELResolver for java.util.Optional

[commodis]

There are often times where a field is better modelled as an Optional<T> instead using a traditional getter for T. Using a getter allows expressions like #{domainObject.optionalProperty.requiredProperty} which resolves the requiredProperty even if the optionalProperty might be null.

• if domainObject.optionalProperty is null then domainObject.optionalProperty.requiredProperty will resolve to null as well
• if domainObject.optionalProperty is not null then domainObject.optionalProperty.requiredProperty` will resolve to its content

This behavior denotes exactly how Optional as map its resolving operation works.

• if domainObject.optionalProperty is empty then domainObject.maybeOptionalProperty().map(OptionalProperty::getRequiredProperty) will resolve to empty as well
• if domainObject.optionalProperty is present then domainObject.maybeOptionalProperty().map(OptionalProperty::getRequiredProperty) will resolve to its content

The current ELResolver does not support this natively and the current specification does not mention java.util.Optional in such way.

I would like to evaluate the expression #{domainObject.optionalProperty.requiredProperty} even though optionalProperty is of type Optional<T>.

[markt-asf]

The requested handling for optional properties is essentially a short-cut for:

#{domainObject.optionalProperty.map(b -> b.requiredProperty).orElse(null)}

I don't like the idea of hard-coding this behaviour by default. It doesn't just add functionality, it changes existing functionality. Some inputs that would have failed with a PropertyNotFoundException would return null instead. If you want to hard-code this behaviour for your application, you could write a simple ELResolver that resolved Optionals this way.

[commodis]

Nobody will provoke a PropertyNotFoundException by using Optional<T> in his getter, thus this will not break any backward compatibilities.

If you want to hard-code this behaviour for your application, you could write a simple ELResolver that resolved Optionals this way.

I actually did this, but since this implementation is self-made, no tooling will ever support this.

I believe the nullable property resolution is one of the greatest features of EL and it should be lifted to a modern Java language level (Java 8 was released 2014!)

[markt-asf]

Given the wide uses of EL, I don't think it is safe to say no-one is depending on a PropertyNotFoundException to signal a missing optional property. Whether they should be doing that is a different question.

What context are you looking to use this in? I'm wondering if providing this behaviour in a OptionalELResolver that could be added as a custom resolver when/where required would be sufficient.

[markt-asf]

No response after 2 months. I am leaning towards closing this as WONTFIX given that a custom EL resolver will meet this requirement.

[commodis]

I actually did this, but since this implementation is self-made, no tooling will ever support this.

The strong point for a specification is, that it is a common ground is laid for tools to operate on. I can for example go to JBoss Tools and tell them that their tool is not operating within the specification and numerous false positives were fixed this way.

As you can see in the upvotes, there is a demand for this feature. If this is not the right place to voice my feature request, where would be the right place?

[markt-asf]

This is the right venue.

I do not consider up votes a reliable indicator of demand. It is too easy to game the system.

If you want to see this issue progressed, answering the question asked on Mar 22 would be a good place to start.

What context are you looking to use this in? I'm wondering if providing this behaviour in a OptionalELResolver that could be added as a custom resolver when/where required would be sufficient.

[commodis]

I thought I explained the context, but it seems I misunderstood. Maybe you can clarify your question?

[markt-asf]

By "context" I mean where are you using EL? In a JSP, with JSF, stand-alone, something else? With the follow-up that is there anything about where/how you are using EL that would mean you couldn't use OptionalELResolver if it were added as a non-default resolver.

[commodis]

I use it within JSF.

I try to define my model using Optional in cases where the property can be null. Now I have to add workarounds to make it usable with EL. Either I can:

• add a getter and/or setter für every child, grandchild etc. property,
• add a specific EL/JSF-compatible domain model representation where I convert every Optional<T>-method to a getter,
• add a utility method to unwrap the optional to null and handle every child and grandchild, or
• I can use the result directly in EL and call .map with a lambda like .map(property -> property.getSubProperty()) (I am unsure about the syntax - I personally think this is getting very unmaintainable).

I am not sure what you mean with non-default resolver? Would that mean, that I have to add some form of configuration to activate it?

[markt-asf]

You'd need to add the Resolver to the default ELResolver as per the Jakarta Pages specification. Whether you need to use JspApplicationContext.addELResolver() or if JSF provides an alternative mechanism I don't know.

The idea is that this would give you the functionality you require without changing the current behaviour.

[commodis]

I wouldn't mind it as a first attempt.

My last attempt used the faces-config.xml to activate my custom ELResolver like

<faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                                  http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd" version="2.2">
    <application>
        <el-resolver>com.sample.package.ELResolverClassName</el-resolver>
    </application>
</faces-config>

but I guess there are multiple ways (especially programmatic ways) to activate a custom ELResolver.

[markt-asf]

OK. My intention is to add an OptionalELResolver which would implement the required behaviour.