Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Deprecation of MessageXxx classes

Hi Dirk

I suggest you open the bug (for 4.17) and we can discuss it there. Please cc me and I will be happy to help.


From:        Dirk Fauth <dirk.fauth@xxxxxxxxx>
To:        eclipse-pmc@xxxxxxxxxxx
Date:        04.06.2020 10:12
Subject:        [EXTERNAL] Re: [eclipse-pmc] Deprecation of MessageXxx classes
Sent by:        eclipse-pmc-bounces@xxxxxxxxxxx


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 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?


On Wed, Jun 3, 2020 at 4:34 PM Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
> +1 to mark from for removal in 4.17

Not really. As per the rules:

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 segment.

But +1 to mark for removal. Note that we have the last planned 4.16 build today.


Lars Vogel <lars.vogel@xxxxxxxxxxx>
03.06.2020 15:58
[EXTERNAL] Re: [eclipse-pmc] Deprecation of MessageXxx classes
Sent by:        

Hi Dirk,

+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
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 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
> I therefore request for removal of those interfaces.
> Greez,
> Dirk
> _______________________________________________
> eclipse-pmc mailing list
> To unsubscribe from this list, visit

Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email:
lars.vogel@xxxxxxxxxxx, Web:
eclipse-pmc mailing list

To unsubscribe from this list, visit

eclipse-pmc mailing list

To unsubscribe from this list, visit
eclipse-pmc mailing list
To unsubscribe from this list, visit

Back to the top