commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [codec] getting the bmpm code out there
Date Fri, 12 Aug 2011 10:19:06 GMT
On 12 August 2011 08:37, Stephen Colebourne <scolebourne@joda.org> wrote:
> I've just noticed this thread.
>
> I'd like to ask those involved to consider if they can find a route
> where the package name and group do *not* change.
>
> - Changing to JDK 5 does not require a a package name change (generics
> are backward compatible if the erased signatures don't change).

+1

> - Removing deprecated methods does not require a package name change

How so?

If there are any external references to them in an application that
cannot be removed, then both old and new jars will need to be
deployed.
Which cannot be done safely in a single classloader (no guarantee
which instance of duplicated classes will be loaded).
AFAIK Maven prevents duplicates anyway.

> (and potentially, we should just leave them in)

+1, unless the deprecated methods are so old that it is guaranteed
no-one is using them.

> - It is far far more user friendly to not have a "new" codec and an
> "old" codec in their path.

+1

> Looking back at [lang], I think that a different focus might have
> allowed 90% of the code to have been compatible and in the same
> package, with 10% in a new package. [codec] might well fit that model
> too.
>
> For example, if a method needs its signature changing, create a new
> method alongside and deprecate the original. Yes, it isn't as pretty,
> but it is generally better for users. Only if there are too many cases
> like this to keep the API sane, should a "new" codec (or any other
> commons lib) be created.

+1

I originally thought NET would need a package change to fix problems
with the NNTP API that used int rather than long, but it turned out to
be possible without too much stale code.

> Stephen
>
>
> On 11 August 2011 23:44, Gary Gregory <garydgregory@gmail.com> wrote:
>> On Thu, Aug 11, 2011 at 4:10 PM, sebb <sebbaz@gmail.com> wrote:
>>> On 11 August 2011 20:56, Gary Gregory <garydgregory@gmail.com> wrote:
>>>> Hello All!
>>>>
>>>> Topic 1: Housekeeping: package name and POM.
>>>>
>>>> The next codec release out of trunk will be major release labeled 2.0,
>>>> the current release is 1.5.
>>>>
>>>> In trunk, I've removed deprecated methods and the project now requires
>>>> Java 5. This means 2.0 will not be a drop-in binary compatible release
>>>> for 1.5.
>>>>
>>>> I'd like to confirm or deny that this means the package name will
>>>> change to o.a.c.codec2 and that the POM groupId will have to change
>>>> from commons-codec to org.apache.commons. 2.0 and 1.5 would be able to
>>>> live side by side.
>>>
>>> Yes, the name changes are necessary to avoid problems with incompatible jars.
>>>
>>>> I'd like to get this out of the way first hence topic 1.
>>>>
>>>>
>>>> Topic 2: Beider-Morse (BM) Encoder API
>>>> https://issues.apache.org/jira/browse/CODEC-125
>>>>
>>>> BM is a new codec for 2.0.
>>>>
>>>> The encode API returns a set of encodings.
>>>>
>>>> In trunk, this is currently a String in the format "s1|s2|s3".
>>>>
>>>> I think this is not the best design, a set should be a Set, in this
>>>> case, an ordered set. Or, a List. Generally, it should be a Collection
>>>> of Strings.
>>>>
>>>> There was concern with call sites that generically use a [codec]
>>>> Encoder with the signature "Object encoder(Object)" and call
>>>> toString() on the result.
>>>>
>>>> If we set the API to "CharSequence encode(Set<CharSequence>)" or
>>>> "String encode(Set<String>)", doing a toString() on a HashSet will
>>>> yield a usable String similar as to what trunk does now. For example,
>>>> for a HashSet of Strings "a", "b" and "c", HashSet.toString() returns
>>>> "[a, b, c]" which no worse than "a|b|c" IMO. At least it is a
>>>> documented and stable format.
>>>
>>> +1
>>>
>>>> Topic 3: Generics
>>>>
>>>> This will be in a separate thread but I'd like to get this in 2.0
>>>> because this will likely break the API and I only want to break things
>>>> once and not have to do a codec3 for generics.
>>>
>>> +1.
>>
>> I'll work on a generified codec2 over the next couple of days and
>> present what that looks like, maybe in a branch, or a patch.
>>
>> Gary
>>
>>>
>>>> Thank you all,
>>>> Gary
>>>>
>>>> On Thu, Aug 11, 2011 at 2:38 PM, Matthew Pocock
>>>> <turingatemyhamster@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> As those of you who've been following the CODEC-125 ticket will know,
with
>>>>> Greg's help I've got a port of the beider morse phonetic
>>>>> matching (bmpm) algorithm in as a string encoder. As far as I can tell,
it's
>>>>> ready for people to use and abuse. It ideally needs more test-case words,
>>>>> but to the best of my knowledge it doesn't have any horrendous bugs or
>>>>> performance issues.
>>>>>
>>>>> The discussion on the ticket started to stray off bmpm and on to policy
for
>>>>> releases and changing APIs, and Sebb said we should discuss it on the
list.
>>>>> So, here we are.
>>>>>
>>>>> Ideally, I'd like there to be a release of commons-codec some time soon
so
>>>>> that users can start to try out bmpm right away, and so that we can start
>>>>> the process of adding it to the list of supported indexing methods in
solr.
>>>>> What do people think?
>>>>>
>>>>> Matthew
>>>>>
>>>>> --
>>>>> Dr Matthew Pocock
>>>>> Visitor, School of Computing Science, Newcastle University
>>>>> mailto: turingatemyhamster@gmail.com
>>>>> gchat: turingatemyhamster@gmail.com
>>>>> msn: matthew_pocock@yahoo.co.uk
>>>>> irc.freenode.net: drdozer
>>>>> tel: (0191) 2566550
>>>>> mob: +447535664143
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thank you,
>>>> Gary
>>>>
>>>> http://garygregory.wordpress.com/
>>>> http://garygregory.com/
>>>> http://people.apache.org/~ggregory/
>>>> http://twitter.com/GaryGregory
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Thank you,
>> Gary
>>
>> http://garygregory.wordpress.com/
>> http://garygregory.com/
>> http://people.apache.org/~ggregory/
>> http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message