rschmitt commented on PR #679:
URL:
https://github.com/apache/httpcomponents-client/pull/679#issuecomment-3104492789
@ok2c I think there should be a higher bar for breaking API changes than
just general cleanup. It's a lot of churn to inflict on users, and a potential
source of bugs. There was one issue for the 5.2 -> 5.4 upgrade which I never
reported, which involved `HttpVersionPolicy` being moved to `TlsConfig`:
```java
@Deprecated
public final HttpAsyncClientBuilder setVersionPolicy(final
HttpVersionPolicy versionPolicy) {
this.tlsConfig = versionPolicy != null ?
TlsConfig.custom().setVersionPolicy(versionPolicy).build() : null;
return this;
}
```
This blows away the prior `tlsConfig`, which in our case contained our
`HttpVersionPolicy`, so the upgraded client suddenly started speaking HTTP/2 in
production, which caused an outage for reasons that aren't relevant here.
Additionally, a recurring issue I have as a maintainer is the lack of late
binding in many of HC's APIs, especially internal ones. There are vast amounts
of constructor delegation, `default` interface methods, arity overloads etc
caused by the insertion of more and more parameters over time. I'd like any
future APIs we add to permit more flexible evolution. The use of `IOException`
here strikes me as suspicious, for example: checked exceptions don't compose
with most of Java 8's functional features and may be wrapped any number of
times, and in async code this gets even more complicated due to
`ExecutionException`, frequent use of `catch (final Throwable t)`, etc.
Finally, I've come to realize that [Reinier Zwitserloot was right about
option
types](https://github.com/projectlombok/lombok/wiki/Language-Design:-Null-vs.-Optional)
(see also [this
post](https://groups.google.com/g/project-lombok/c/ROx9rGRb6lI/m/EF0lk8F0N10J)).
The lack of any type system relationship between `T` and `Optional<T>` adds a
ton of friction for basic code reuse and composition; it's worse than
`const_cast` in C++. Option types only make sense in a limited context where
you need to be able to call methods on a receiver (e.g. in streams, which is
why `Optional<T>` was added). In the long term I think that Java, through the
Valhalla project, is moving in a direction where nullability is not just
explicitly modeled in source code, but is reified at runtime as well in a way
that enables JIT compiler optimizations like layout flattening. So I think we
should stay the course with nulls instead of trying to use option types in new
APIs. We can use JSpecify annotations if we
really must, although they entail some annoyances for consumers like breaking
`-Werror`.
--
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: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
