RFR: JDK-8323706 Move SimpleSelector and CompoundSelector to internal packages

[Kevin Rushforth]

On Sun, 14 Jan 2024 14:54:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
> 
> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
> 
> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
> 
> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
> 
> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
> - No need anymore for the `SimpleSelectorShim`

I'll take a closer look tomorrow, but this will very likely need to be done in two steps. Step 1 would be to terminally deprecate the existing public classes in an exported package. Step 2 would then be to remove them from the public API by moving them to a non-exported package. Given that we are still in RDP1 for JavaFX 22, we could do the first step (terminal deprecation) in 22 paving the way for removal in 23, so the net result would be the same, but it would give a clear warning to anyone using JavaFX 22 that this removal is pending.

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-1892500082