rschmitt commented on PR #773: URL: https://github.com/apache/httpcomponents-client/pull/773#issuecomment-3713826988
> @rschmitt So, what are we going to have at the end of it? The old default behavior that we all agree is outdated and wrong will still be there but on top of it we are going to introduce some non-standard system property to flip the behavior. So, instead of fixing the problem we are going to make it even messier. Is this wise? Yes. It's wise, because it maintains backwards compatibility while following established conventions for Java library development. It's totally normal for Java libraries to define their own namespaces for system properties (e.g. `io.netty` for Netty, `org.asynchttpclient` for async-http-client). In fact, async-http-client did [exactly what I'm proposing we do](https://github.com/AsyncHttpClient/async-http-client/blob/main/client/src/test/java/org/asynchttpclient/proxy/ProxyTest.java#L246), in order to accommodate the [same use case](https://stackoverflow.com/a/68985455). What I've conceded is both outdated and wrong is the insistence on not even _querying_ system properties. Beyond that, it's not clear to me which system properties should be respected by default, even without taking backwards compatibility into account. The proxy-related properties seem reasonable; `http.agent` does not. > Every time we make a minor release there is always someone unhappy because it turns out they should have read the release notes and / or have moved off some deprecated APIs. I don't like changes that presume upon our users' ability to "just" move off deprecated APIs. Not everyone controls their execution environment and their runtime classpath. The caller of some deprecated API may itself be a library, which doesn't get the final say in which versions of httpcore5 and httpclient5 are present at runtime. Or a user may be deploying code into a runtime image they don't control, which provides third-party dependencies like the Apache client (I've worked with EMR before, which is an example of this sort of thing). We shouldn't assume that users can upgrade their Apache client _and_ modify their code to account for breaking changes in a single atomic update, and we shouldn't even assume that users can code against a single version of the Apache client as opposed to a whole range of versions. > We should be fixing problems as we discover them even at the cost of upsetting a few folks. Fixing problems properly pays off in the long run. This brings me back to my original point: the actual problem we are trying to solve is one of _locus of control_, and this problem has an easy, 100% backwards-compatible fix. There's no need to get sidetracked arguing about what the defaults are, whether to change them, how many API symbols to add or deprecate, etc. My repeated experience dealing with software upgrades at scale is that most breaking changes are frivolous, in the sense that the goal they were aiming at could have been done nearly as easily in a backwards-compatible way. I'd rather save our breakage budget for the bugs that _can't_ be fixed compatibly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
