Re: [eclipse-pmc] Deprecation of MessageXxx classes

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

Ah right, there's
already a bug. We can use that one.

Dani



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

---

Hi Dani,

Should I create a new bug or should I
use the existing one? 

Greez, 
Dirk 

Daniel Megert <daniel_megert@xxxxxxxxxx>
schrieb am Do., 4. Juni 2020, 10:46:
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.

Dani



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

---

Hi,

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?

Greez,
Dirk

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.

Dani



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

---

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

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: http://www.vogella.com
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc




_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc



_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc