Incremental delete of duplicate interfaces (IInvocationContextCore and IProblemLocationCore)

[robstryker]

What it does

There is a massive duplication of interfaces that have appeared as code has moved from jdt.ui to jdt.core.manipulations. Most of these interfaces never had any reason to exist, as the original interfaces could have simply been pushed down to the core plugin directly. This PR is the first step in removing some of the identical and duplicate interfaces.

This PR consists of a single commit above the above-mentioned PR dependency, and it effectively does the following: Removal of internal interfaces IInvocationContextCore and IProblemLocationCore

Both of these interfaces are identically duplicated by IInvocationContext and IProblemLocation respectively. This should be a very painless migration, even for illegal extenders like jdt.ls.

Why this is needed

While pushing code related to the completion subprocessors from jdt.ui to jdt.core.manipulations, one specific (and hefty) subprocessor, LocalCorrectionsSubProcessor, uses a lot of proposals that wrap CleanUp objects, using either the ICleanUp or ICleanUpCore interfaces, as well as the AbstractCleanUp or AbstractCleanUpCore abstract classes.

While identical interfaces are not much of a problem, having two parallel-but-slightly-different abstract classes leads to two parallel heirarchies, and clients can not simply extend both or support both very easily. While trying to untangle these specific issues, the myriad of other duplicate (and otherwise harmless) interfaces that are in the affected code also begin to add complexity to the solution.

With that in mind, removing the most unoffensive interfaces first becomes the safest course of action, while at the same time building our way up to tackling the larger parallel-heirarchy issue via small and manageable changes to the heirarchy as the situation becomes less cluttered.

How to test

Removal of two identically-duplicated internal interfaces should not have much of an affect on the behavior of the codebase at all. The existing test suite should be more than sufficient.

Author checklist

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[rgrunber]

The IInvocationContextCore & IProblemLocationCore were created so that JDT-LS could make use of that functionality directly. If they can be removed, and replaced with the "non-core" named versions that are accessible in jdt.core.manipulation, that seems fine. There's a JDT-LS release planned soon, so I might prefer to wait until maybe the end of the week before merging, assuming all is fine.

[robstryker]

Inspecting the changed files to see how many changed files have internal in their path results in the following:

[rob@fedora eclipse.jdt.ui] (IncrementalDeleteOfDuplicateInterfacesPart1)$ git diff --stat=1000 HEAD~2 HEAD | grep -v internal | grep -v tests
 org.eclipse.jdt.core.manipulation/.settings/.api_filters                                                                                     |   8 ++++++++
 {org.eclipse.jdt.ui/ui => org.eclipse.jdt.core.manipulation/proposals}/org/eclipse/jdt/ui/text/java/IInvocationContext.java                  |  13 +++----------
 org.eclipse.jdt.core.manipulation/proposals/org/eclipse/jdt/ui/text/java/IProblemLocation.java                                               |  12 +-----------
 org.eclipse.jdt.ui/.settings/.api_filters                 

In short, the only API classes that have been modified are IProblemLocation and IInvocationContext, and the API tools have determined that these interfaces did not in fact change at all.

[jukzi]

green build now

[rgrunber]

Change looks good to me. Just a few comments on some minor things.