Re: [MNG-6164] Collections inconsistently immutable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6164] Collections inconsistently immutable

Robert Scholte-6
+1

Robert

On Sun, 28 May 2017 12:01:20 +0200, Michael Osipov <[hidden email]>  
wrote:

> Am 2017-05-25 um 21:12 schrieb Michael Osipov:
>> Who seconds MNG-6164 for 3.5.1?
>>
>> This is a non-functional consistency fix. All ITs pass.
>
> Anyone?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6164] Collections inconsistently immutable

Michael Osipov-2
Am 2017-05-28 um 13:01 schrieb Hervé BOUTEMY:
> I'm not confident on this one.
>
> I understand the inconsistency issue, that may lead to edge-case issues in
> plugins or extensions (that unexpectedly get an immutable empty list when they
> usually get a modifiable non-empty list)
>
> Is it the right solution to change every non-empty list to immutable?

Neither is unless you exactly know how the lists will be used.

> Why wouldn't be the solution to make every returned empty list mutable?

This is also I am not in favor of neither one, but it has to be
predictable, thus consisitent.

> Or a mix: on some cases, immutable is a good feature, but on others consistent
> mutable would be the good choice?

The caller does not know wether he will receive a populated or empty list.

> Do you know how many plugins or extensions this update will break?
> I know that consistent breaks are better than inconsistent breaks (on empty
> lists), but is it the right time to take such risk?

I can run all plugin ITs from our aggregator and see how they work.

> I know that core ITs pass: that does not mean that external plugins won't
> break (thousands in Central only, I don't know how many corporate plugins
> exist)
>
>
> How many cases are changed? In which areas of Maven API?
> That is the information I need to vote for this change, knowing the effective
> impact it will have

As far as I can see for the changes, they all look like read-only
structures.

I fully understand your concerns. Let me run plugins ITs and see return,
we can postpone to 3.6 if we think this is too problematic.

Michael

> Le dimanche 28 mai 2017, 12:01:20 CEST Michael Osipov a écrit :
>> Am 2017-05-25 um 21:12 schrieb Michael Osipov:
>>> Who seconds MNG-6164 for 3.5.1?
>>>
>>> This is a non-functional consistency fix. All ITs pass.
>>
>> Anyone?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...