RFR: JDK-8322964 Optimize performance of CSS selector matching [v3]

[John Hendrikx]

On Sun, 14 Jan 2024 04:20:56 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> This is possible, although `List#get` would not perform too well when it is implemented for `FixedCapacitySet.OpenAddressed` as the array used as hash table in this class can have gaps (so we'd need to iterate to find the index).
>> 
>> However, I am very sure this method is not used anywhere (not even in 3rd party code as it requires casting to access), and I wouldn't encourage its use, so I'd be more inclined to remove it completely.
>
> If this method is not used anywhere, why do we need to expose `getStyleClassNames()` as new API to replace this one? I'm a bit puzzled by that, especially since you're saying that the API shouldn't be used. Why create something that shouldn't be used?
> 
> I'd rather just document that you shouldn't expect great performance from this method, and be done with it. Changing API in a performance optimization PR seems out of scope.

@mstr2 I've created #1333 to show how it would look when we move `SimpleSelector` and `CompoundSelector` to internal packages.  I think that should alleviate most concerns, and we can either integrate this first with a new public method, which will later be internal anyway, or integrate the other change first.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1451751294