CLDR-17540 update SupplementalDataInfo reader to not use reentrant XPathParts

[srl295]

note this is for v46 - see also #3631

• clarify distinction between XPathParts and SimpleXPathParts
• push XPathParts.size() and other API up to XPathValue.size()
• use SimpleXPathParts instead of XPathParts in SupplementalDataInfo

CLDR-17540

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[srl295]

this was more work than made sense for v45 so split out.

[macchiati]

A downside of SimpleXPathParts is that it doesn't cache, right? That should be mentioned here also, because it is a downside to using SimpleXPathParts for repeated usage.

[srl295]

Yes. This should say, static init time where XPaths that are going to be read only once are used. Especially supplemental data, where all XPaths are unique and caching doesn't help.

[macchiati]

It would be better to return an ImmutableMap; that way we are guaranteed that nothing can change it.

Can discuss tradeoffs offline.

[macchiati]

That is, something like the following.

• from public Element makeImmutable() {
• extract the following into a method in a common location

            if (attributes != null && !(attributes instanceof ImmutableMap)) {
                attributes = ImmutableMap.copyOf(attributes);
           }

• From public XPathParts freeze() {
• extract the following into a method in a common location, changing to call the above method instead of Element.makeImmutable()

            // ensure that it can't be modified. Later we can fix all the call sites to check
            // frozen.
            List<Element> temp = new ArrayList<>(elements.size());
            for (Element element : elements) {
                temp.add(element.makeImmutable());
            }
            elements = ImmutableList.copyOf(temp);

• then change the following to call that method after the handleParse call

    SimpleXPathParts(String xpath) {
        handleParse(xpath, true);
    }

There are alternatives, eg copy the code into SimpleXPathParts, or have an Elements base class, etc.

[srl295]

PROBLEM: exposes internal map comment and code is from the original XPathParts implementation. Perhaps that's a good follow up item as a separate concern from this one?

[macchiati]

Makes sense. Can you clone a ticket for that?

[srl295]

https://unicode-org.atlassian.net/browse/CLDR-17565

[srl295]

@macchiati PTAL, updated the comments. The immutability is in another ticket