<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 3/26/14 1:48 PM, Rod Widdowson
      wrote:<br>
    </div>
    <blockquote
      cite="mid:009701cf491b$8b7614f0$a2623ed0$@steadingsoftware.com"
      type="cite">
      <pre wrap="">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. </pre>
    </blockquote>
    <br>
    Well, on the stuff in that package specifically...&nbsp; 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.&nbsp; By this I'm talking about the cases where the class/method
    name refers to a class or interface in some third-party API.<br>
    <br>
    For example, there we have HttpClientBuilder.&nbsp; It's not a builder of
    some kind of "HTTP client".&nbsp; It's a builder of a specific named
    thing, from another library, called HttpClient.&nbsp;&nbsp; <br>
    <br>
    Same thing for HttpServletRequest/-Response and things of a similar
    nature.&nbsp; E.g we currently have ThreadLocalHttpServletRequestProxy
    and that would stay the same<br>
    <br>
    I'm not saying we can't reverse course and do something different,
    but that's what I thought the plan was.<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote
      cite="mid:009701cf491b$8b7614f0$a2623ed0$@steadingsoftware.com"
      type="cite">
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    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).<br>
    <br>
    <br>
    <br>
  </body>
</html>