Clarify inconsistency between Spec Section 1.6 (`value-b` is `null`) and `MapELResolver` Javadoc regarding `null` keys

Open
  • Is something wrong?
#500 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 7 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
testing

Research direction

Start by comparing specification Section 1.6 with the MapELResolver Javadoc for getValue, setValue, and isReadOnly, then check the existing TCK tests for EL map access. The issue asks whether null keys in expressions should short-circuit and whether a test should cover ${map[null]} when the map contains a null key. Done means the intended behavior is resolved and the specification or TCK coverage is updated accordingly.

Written by the indexing model from the issue text.

Description

There is an inconsistency between Section 1.6 ("Operators [] and .") of the Jakarta Expression Language 6.1 specification document and the Javadoc of jakarta.el.MapELResolver:

  1. Specification Document — Section 1.6 ("Operators [] and ."):

    To evaluate expr-a[expr-b] or expr-a[expr-b](params):

    • Evaluate expr-a into value-a.
    • [...]
    • Evaluate expr-b into value-b.
    • If value-b is null:
      • If expr-a[expr-b] is the last property being resolved:
        • If the expression is a value expression and ValueExpression.getValue(context) was called to initiate this expression evaluation, return null.
        • Otherwise, throw PropertyNotFoundException. [trying to de-reference null for an lvalue]
      • Otherwise, return null.
  2. jakarta.el.MapELResolver Javadoc (getValue, setValue, isReadOnly):

    @throws NullPointerException if context is null, or if the key is null and this map does not permit null keys (the latter is optionally thrown by the underlying Map).

Because Section 1.6 mandates returning null (for getValue) or throwing PropertyNotFoundException (for setValue/getType/isReadOnly) whenever value-b is null before invoking elResolver, MapELResolver is never invoked with property == null during EL expression evaluation (e.g. ${map[null]}), even when the underlying Map (such as HashMap) contains a mapping for the null key.

Steps to Reproduce
import jakarta.el.ELProcessor;
import org.junit.jupiter.api.Test;
import java.util.HashMap;
import java.util.Map;
import static org.junit.jupiter.api.Assertions.assertNull;
public class MapNullKeyTest {
    @Test
    void testMapWithNullKey() {
        Map<String, String> map = new HashMap<>();
        map.put(null, "null-key-value");
        ELProcessor processor = new ELProcessor();
        processor.defineBean("map", map);
        // Following Section 1.6, expr-b evaluates to null and short-circuits to null
        // without calling MapELResolver.getValue(context, map, null)
        Object result = processor.eval("map[null]");
        assertNull(result);
    }
}
Question / TCK Request
  1. Is the null key handling in MapELResolver intended strictly for direct programmatic calls to ELResolver#getValue(context, base, null), while EL expressions ${map[null]} must always short-circuit to null per Section 1.6?
  2. Could a TCK test be added for ${map[null]} (when map contains a null key) to explicitly validate Section 1.6 compliance?
Dominant language
Java
Stars
86
Forks
54
Avg merge
6d 9h
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from jakartaee/expression-language

All issues in jakartaee/expression-language

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.