Upper casing classes in Java-support

[Brent Putman]

On 3/26/14 1:48 PM, Rod Widdowson wrote:
> Since Ian has been asking about this:
>
> My investigations into the metadata parsers has led me to the code in
> net.shibboleth.utilities.java.support.httpclient.  This has a whole bunch of
> classes with old style camel case names. 

Well, on the stuff in that package specifically...  I had previously
brought up this kind of case and we agreed (at least as far as people
expressed an opinion at that time) that we wouldn't rename these.  By
this I'm talking about the cases where the class/method name refers to a
class or interface in some third-party API.

For example, there we have HttpClientBuilder.  It's not a builder of
some kind of "HTTP client".  It's a builder of a specific named thing,
from another library, called HttpClient.  

Same thing for HttpServletRequest/-Response and things of a similar
nature.  E.g we currently have ThreadLocalHttpServletRequestProxy and
that would stay the same

I'm not saying we can't reverse course and do something different, but
that's what I thought the plan was.

For consistency, we do have plenty of cases where the lower class class
names are in fact out-of-sync with the actual third-party API usage,
like Type4UuidIdentifierGenerationStrategy and Slf4JLogChute, where we
do clearly need to rename to upper case.


> While I'm here I'll note that net.shibboleth.utilities.java.support.net has
> a smattering of Uri and Url named classes, whilst
> net.shibboleth.utilities.java.support.net has both XMLParserException and
> XmlSpace and XmlConstants, as well as DomTypeSupport.

Yeah, those are clearly candidates for renaming, and are often in some
cases out of sync with the API they are supporting (e.g. java.net.URI).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140326/62fc02b4/attachment.html