commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [VOTE] Release Codec 1.4 based on RC2
Date Sat, 25 Jul 2009 18:48:32 GMT
> -----Original Message-----
> From: Emmanuel Bourg []
> Sent: Saturday, July 25, 2009 11:13 AM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Codec 1.4 based on RC2
> I looked quickly at the new classes, I'm not convinced by the benefit of
> the RequiredCharsetNames class in the codec API. I understand it's
> useful internally to factorize some string constants in the classes, but
> as a user I don't think I would ever use it myself.

Hello Emmanuel,

Indeed, code and tests use the RequiredCharsetNames constants, from different packages and,
as we know, there is no way in Java to make a class useable across packages without making
it public. This is why I made the class public and move it to a more logical package. 

OSGi tries to fix that with the export-package directive in the manifest, so we could try
to use that feature to make this class 'project private' or document it as such. That would
be a little ugly since I think the export-package granularity is that the package level. That
is not something I would like to see.

Actually, RequiredCharsetNames is like [lang]'s CharEncoding [1] (
But we've never wanted this kind of dependency from codec->lang.

In work code, we have used [lang]'s CharEncoding and our own similar classes to provide what
should be in the JRE IMO. There is definitely a need for (1) having the required-always-there
charset names defined somewhere and (2) having some utility methods that provide unchecked
exception version of some common operations. In this case, the common operations are inspired
by refactorings in codec itself.

As I have seen in other projects, we could copy [lang]'s CharEncoding to [codec] to make things
more consistent. Well, in this case, that is just renaming RequiredCharsetNames to CharEncoding,
which be more recognizable for people already familiar with [lang]. That seems like a good

All of this to say that I think the class has its place since codec is about encoding and
decoding bits and charset encodings are part of that.

> Regarding the StringBytesUtils class, why doesn't it follow the general
> scheme of the API with encoder/decoders? I would probably expect a
> CharsetEncoder and a CharsetDecoder class. I guess the intent is just to
> provide utility methods swallowing the UnsupportedEncodingException?

StringBytesUtils does not follow the general pattern because that is beyond the goal I had
for the refactoring: remove code duplication, which improved code coverage as a side effect.

Note that when using StringBytesUtils methods that specify a required encoding, there is no
UnsupportedEncodingException to swallow because it will never be thrown, unless I suppose
your JRE is severely corrupted, in which case, the checked UnsupportedEncodingException is
turned into an unchecked IllegalStateException, so the exception is in fact *not* swallowed,
but re-thrown.

DigestUtils does not follow the pattern either. ;)


> Emmanuel Bourg
> Niall Pemberton a écrit :
> > I have prepared a second release candidate for Codec 1.4 following the
> > feedback (thanks!) from the first.
> >
> > [ ] +1 Yes go ahead an release based on RC2
> > [ ] -1 No, because...
> >
> > The tag for RC2 is here:
> >
> >
> > The release artefacts are here
> >
> >
> > Site is available here:
> >
> > (note: some links are relative and will be broken until deployed to
> > proper codec home)
> >
> > RAT Report:
> >
> >
> > CLIRR Report:
> >
> >
> > Release Notes:
> >
> >
> >
> > Thanks
> >
> > Niall
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message