I am a bit confused on how to proceed now. I should mark the 3 interfaces
with @noreference, @noextend and @noimplement. If I do this the API tooling
tells me that I need to update the major version of the core.services bundle
to 3.0.0. Is that correct?
Then I should deprecate the using API and add an updated API to be
used instead. But the interfaces can be replaced with the java.util.function
interfaces directly. The MessageXxx interfaces were intended to be used
with Java 8 lambdas. So if I introduce new methods that take the Java functional
interfaces and deprecate the old ones, the usage of the methods with lambdas
complain about deprecation because the old methods are still used by the
compiler. I am not 100% sure, but I suppose it is because of the target type
inference algorithm that first uses matching custom implemented interfaces
before falling back to default functional interfaces. But to be honest,
I have not found information about that detail in target typing.
Anyhow, the issues should be located in BaseMessageRegistry. The interfaces
were introduced for lambda usage. Therefore implementing the MessageXxx
interfaces should not have happened (but you never know). Also the methods
in BaseMessageRegistry should not have been overridden. But as they are
not marked as final, it could have happened.
So should I only mark the interfaces and increase the plugin version? I
also tried for a start to extend the java.function interfaces so internally
the BaseMessageRegistry operates on them. But that does not solve the API
usage of BaseMessageRegistry. Or is there some mechanism that I missed
that would help in making such a change backwards compatible?
7. If there is no substantial community disagreement (the PMC may
decide to cancel the change if the impact of removal outweighs the benefits)
and after the two year waiting period has gone by, the API is removed
and the porting guide entry is moved from the "Planned API removals"
to the "Removed APIs" section in the documentation. In general,
removing a deprecated API does NOT cause the increase of the major version
But +1 to mark for removal. Note that we have the last planned 4.16 build
+1 to mark from for removal in 4.17, direct deletion is not possible due to our API guidelines.
Here is what needs to be done (see https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process) --------- Annotate all APIs that are to be removed with @noreference, @noextend and @noimplement where applicable, update deprecation comment and add an entry in the porting guide. Do the same for the API that depends on it. The deprecation comment and porting guide entry must explain how to adapt the client code and also include a link to the bug report to allow feedback from API adopters. -------- IIRC you requested this already a longer while ago. Please mark them this time for deletion so that we can retire them in a few years.
Best regards, Lars
On Wed, Jun 3, 2020 at 3:53 PM Dirk Fauth <dirk.fauth@xxxxxxxxx>
wrote: > > Dear PMC, > > some years ago I introduced the following three interfaces: > > MessageConsumer > MessageSupplier > MessageFunction > > It was because a dependency to Java 8 was not yet available for the
Eclipse Runtime. The idea was always to replace those interfaces with the
java.util.function interfaces. But with publishing the org.eclipse.e4.core.services.nls
package as API the change was not that easy anymore. And I forgot about
it to be honest. > > To clean up I would like to remove those interfaces and replace them
with default interfaces. The related bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=512665 > > I therefore request for removal of those interfaces. > > Greez, > Dirk > _______________________________________________ > eclipse-pmc mailing list > eclipse-pmc@xxxxxxxxxxx > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc
-- Eclipse Platform project co-lead CEO vogella GmbH