I've been thinking exactly this thing, and here you proposed it :-). I also mentioned it to Jason at the hackathon.
People expect to have an "HttpSolrClient" type; the recent Solr MCP was using it -- perhaps written in part by an LLM that knows about HttpSolrClient's pervasiveness. And who can blame any person or LLM for using such an obvious name like that. What a great name! Our issue as a project is the *implementation*. HTTP: * HttpSolrClient base type; not much if any implementation * HttpJettySolrClient (formerly known as Http2SolrClient) * HttpApacheSolrClient (formerly HttpSolrClient). * HttpJdkSolrClient (already named well). CLOUD: * CloudSolrClient base type * CloudJettySolrClient (from CloudHttp2SolrClient) * CloudApacheSolrClient (currently CloudLegacySolrClient). One could argue just leave it be given how soon it will be deleted * (no JDK variant exists yet, sadly) LB: (I dislike that the B is capitalized; would prefer to lowercase that) * LBSolrClient base type * LBJettySolrClient (from LBHttp2SolrClient) * LBApacheSolrClient (from LBHttpSolrClient) * (no JDK variant exists yet) CONCURRENT UPDATE * NO ConcurrentUpdateSolrClient base abstraction needed? Or just add it with nothing * ConcurrentUpdateApacheSolrClient (from ConcurrentUpdateSolrClient) * ConcurrentUpdateJettySolrClient (from ConcurrentUpdateHttp2SolrClient) Using a sequence of "git mv" operations on multiple commits, we could retain source control history, even though the project wouldn't build at a specific intermediary commit. All that would be Solr 10 only, but Solr 9 could un-deprecate HttpSolrClient along with documentation explaining what's happening. Of course, all of this will be quite disruptive to anyone with WIP on these very classes. James Dyer, I'm thinking of you. On Sat, Sep 27, 2025 at 7:57 AM David Eric Pugh <[email protected]> wrote: > Looking at Http2SolrClient after talking to David S the other day, and boy > is it confusing. I thought it was the "client that speaks Http 2", not > "the second Http Client that speaks 1 and 2". > We have a javadoc:* <p>Despite the name, this client supports HTTP 1.1 and > 2 -- toggle with {@link > * HttpSolrClientBuilderBase#useHttp1_1(boolean)}. In retrospect, the name > should have been {@code > * HttpJettySolrClient}.With Solr 10 coming up, should we have a > HttpJettySolrClient that then is extended by Http2SolrClient and go ahead > and deprecate Http2SolrClient? > Or, just rip the bandaid off, and deprecate Http2SolrClient in 9x, and > introduce HttpJettySolrClient in 10? I'm guessing usage of > Http2SolrClient out in the wild isn't yet prevalent. > Or neither...
