Remove dependency of decl. hints on hints UI; UI plugs into hints SPI.

[sdedic]

The original idea was to ditch java.hints.ui from the LSP server, as it is Swing-based, but I've realized that java.hints.declarative depend on the ui directly just because of one call.
I made a SPI to plug hints UI implemented in java.hints.ui and (private) API in spiimpl that displays the UI - so now java.hints.declarative only (implementation-)depends on spi.java.hints.

[matthiasblaesing]

Looks sane to me. I don't think this is strictly an API change - the documented change is not part of the exposed API, but that is a side discussion. I also think some methods could have lower visibility (for example openRefactoringUI), but as this is not API, I think it is ok.

[sdedic]

Looks sane to me. I don't think this is strictly an API change - the documented change is not part of the exposed API,

I'ts not, but the spiimpl package is a semi-api (or this is how it is used by other hint modules). An API should have been created ages ago from the package...

I also think some methods could have lower visibility (for example openRefactoringUI), but as this is not API, I think it is ok.

Please elaborate. Speaking about org.netbeans.modules.java.hints.spiimpl.Utilities::openRefactoringUI - the intention was to expose a helper ("api") method that would locate & call the plugged SPI implementation or fail; the method is likely to be called from different packages, hence it should be public ...

[matthiasblaesing]

Looks sane to me. I don't think this is strictly an API change - the documented change is not part of the exposed API,

I'ts not, but the spiimpl package is a semi-api (or this is how it is used by other hint modules). An API should have been created ages ago from the package...

Understood.

I also think some methods could have lower visibility (for example openRefactoringUI), but as this is not API, I think it is ok.

Please elaborate. Speaking about org.netbeans.modules.java.hints.spiimpl.Utilities::openRefactoringUI - the intention was to expose a helper ("api") method that would locate & call the plugged SPI implementation or fail; the method is likely to be called from different packages, hence it should be public ...

Yeah I noticed, that openRefactoringUI is only called from openRefactoringUIOrWarn, so could be private. But I think it is ok to keep as is, as it might satisfy other usecases where the caller wants to handle missing UI implementations.

So I still think this is ok to merge.