On Wed, 8 Apr 2026 22:28:05 GMT, Naoto Sato <[email protected]> wrote:
>>> What if tags contains null element, but matching element enumerates earlier >>> in the Collection? Looks like the implementation simply returns when the >>> matching one comes first in the loop, not caring the null in the rest of >>> the collection. >> >> @naotoj You're right. I wanted to keep the checks out of the standard-path >> case if possible. But it looks like to ensure this behavior for an early >> match (and possible subsequent null elements later), we will need to >> validate all cases up-front. One alternative is weakening the specified >> NullPointerException to "_may throw_" for null elements within the >> collections, if the up-front performance cost is a concern. > >> One alternative is weakening the specified NullPointerException to "_may >> throw_" for null elements within the collections, if the up-front >> performance cost is a concern. > > Yeah, this seems more accommodating. We could explicitly state in the spec > that early matching is allowed. @naotoj Something to note is that for all APIs, the priority list is eagerly iterated on, so no null elements can be hidden there. The locale collection accepting APIs eagerly convert locales to tags as well, so the problem only arises for tags. The `filter` and `filterTags` APIs also traverse the entire tag list during scanning. Thus this early return issue lies only in `lookupTag`. So there is another question of whether we want to use this "weaker" specification for all the APIs, or just `lookupTag`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30632#issuecomment-4210444620
