Class/method naming conventions (yes, again....)

[Brent Putman]

Back in the spring, by decision of the majority, we decided upon
uppercase naming conventions for acronyms in class and method names,
e.g. we use getLDAPURL, not getLdapUrl.  A couple of issues:

1) Much/most of java-support was written by Chad, using his preferred
camel case convention, which is now counter to that policy.  We are
assuming a release in the near future of java-support 2.0.0 to support
some of Ian's work.  I have forgotten exactly what the timeframe for
that is, but do we want to implement the naming convention change for
java-support 2.0.0, or just defer it to a later release (which of
necessity be a new major version)?  We have a lot of this renaming work
to do across all the projects, so maybe it's best to do it all at once,
rather than piecemeal?

2) I don't remember us discussing the following special case re:
acronyms and naming:  Often times we have a class name or a
getter/setter, etc that is related to building or accepting or
manipulating or returning a third-party class which contains acronyms in
its name.  Often those third-party classes do not use the upper-case
convention, e.g. HttpServletRequest/-Response, Apache's HttpClient, etc. 

For those cases I personally think it makes the most sense, and would
formally propose, that we use the case that conforms to the third-party
library's usage.  For example, a class/interface would have a
getHttpServletRequest() method, not getHTTPServletRequest.  A builder
class would be HttpClientBuilder, not HTTPClientBuiler.

My rationale is that for example you're not working with an instance of
an "HTTP client"  or an "HTTP request" (in some general sense), but
rather specifically an instance of a thing called "HttpClient" and
"HttpServletRequest".  So basically treat it as an opaque, immutable
name, not an acronym.

Note that this cuts both ways, e.g. we have a UriSupport class with
manipulates java.net.URI instances and so would become URISupport. 

Opinions? Dissent?

We have several instances of things like this in java-support, so that's
why I noticed it now.

Thanks,
Brent