> -----Original Message----- > From: Emmanuel Bourg [mailto:ebo...@apache.org] > 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] (http://commons.apache.org/lang/api/org/apache/commons/lang/CharEncoding.htm). 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 change. 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. ;) Gary > > 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: > > http://svn.apache.org/viewvc/commons/proper/codec/tags/CODEC_1_4_RC2/ > > > > The release artefacts are here > > http://people.apache.org/~niallp/codec-1.4-rc2/ > > > > Site is available here: > > http://people.apache.org/~niallp/codec-1.4-rc2/site/ > > (note: some links are relative and will be broken until deployed to > > proper codec home) > > > > RAT Report: > > http://people.apache.org/~niallp/codec-1.4-rc2/site/rat-report.html > > > > CLIRR Report: > > http://people.apache.org/~niallp/codec-1.4-rc2/site/clirr-report.html > > > > Release Notes: > > http://people.apache.org/~niallp/codec-1.4-rc2/site/changes-report.html > > http://people.apache.org/~niallp/codec-1.4-rc2/RELEASE-NOTES.txt > > > > Thanks > > > > Niall > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
