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

[Tom Zeller]

>>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)?
>
> I think chances we won't need a 3.0 anyway are very low, so I'd suggest
> deferring.

Defer. I think Rod has refactoring on his list.

>>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.
>
> Yes, I ran into a few cases like that and was leaving them alone on the
> assumption that's what we'd want.

Okay with me.