commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] 1.10 regression / backwards-incompatible change in MapConfiguration.convertPropertiesToMap ?
Date Thu, 14 Jan 2016 10:33:55 GMT

Am 13.01.2016 um 23:23 schrieb Gary Gregory:
> On Wed, Jan 13, 2016 at 11:43 AM, Norbert Kiesel <>
> wrote:
>>> Hi Norbert,
>>> due to lack of time, I recently only focused on Configuration 2.0 and
>>> intended to let the 1.x series slowly die. Therefore, my priority is to
>>> get 2.0 ready and push the release out. If I understand correctly, the
>>> implementation in 2.0 satisfies your needs, except that some generic
>>> types still have to be adapted (passing a Map<String, ?> to the
>>> constructor rather than a Map<String, Object>). Is this correct?
>> Yes, 2.0 satifies our need (even the current version, though I agree with
>> your
>> suggested type change).
>>> Patches for a 1.11 fix release are of course welcome, but I cannot
>>> promise that I will be able to actually do a 1.11 release in the near
>>> future. If somebody else steps up and volunteers to do this, this would
>>> of course be another story.
>> Understood.  Really only trying to help here, not to produce more work for
>> you
>> or the community.  We will simply stick with 1.9 until 2.0 is out.
>>> ...
>>>> The way out for a potential 1.11 would be to override more of the the
>>>> AbstractMap API to make that a mutable map backed by the Properties
>> object.  Do
>>>> you want me to provide a patch along these lines?
>>> This approach would probably work, but it seems like unnecessary
>>> complexity. Accessing the passed in Properties object directly - as done
>>> in 2.0 - is more straight-forward, isn't it?
>> This would break backwards compatibility: 1.x promises to actively weed out
>> entries with non-string keys from the passed Properties object. So anyone
>> depending on this would be in for a surprise.  2.0 instead warns callers
>> that they have to
>> ensure that they don't pass such entries.  This makes life simpler for the
>> implementation
>> and is IMHO very good for an API-breaking 2.x but not for 1.x.
>> I don't want to waste anyone's time here, so unless you tell me that you
>> want to see the
>> revised patch or otherwise actively engage, I will shut up on this topic.
>> Was a pleasure to
>> talk to you and thanks for your community work!
> Thank you for your understanding and help. We are all volunteers short on
> time.
> You might want to submit a 1.x patch in case an RM decides to push out a
> release. That would grease the wheels a bit. Just in case...
> Gary

Full agreement to what Gary said. Many thanks for your support and
constructive feedback, Norbert!


>> </nk>
>> Confidentiality Notice:This email and any files transmitted with it are
>> confidential and intended solely for the use of the individual or entity to
>> whom they are addressed. This message contains confidential information and
>> is intended only for the individual named. If you are not the named
>> addressee you should not disseminate, distribute or copy this e-mail.
>> Please notify the sender immediately by e-mail if you have received this
>> e-mail by mistake and delete this e-mail from your system. If you are not
>> the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message