RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange usability [v4]
Ethan McCue
duke at openjdk.org
Thu Jun 20 15:16:13 UTC 2024
On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:
>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
>
> - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>
> # Conflicts:
> # src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
> - update api changes based on comments
My reasoning is as follows
* Once we add something, we can't remove it. Even if we deprecate it, it will still be there
* The ideal API, in my head, is something like the following
exchange.sendResponseHeaders(200, ResponseLength.unknown());
exchange.sendResponseHeaders(200, ResponseLength.known(0));
exchange.sendResponseHeaders(200, ResponseLength.known(body.length));
exchange.sendResponse(200, Body.of("Hello, world"));
* That API, specifically `Body.of`, would be more naturally tempting to use.
* If we have `ResponseLength.unknown()` and `ResponseLength.known(0)` as options, the constants are redundant
* The constants do not address the case of "you get an arbitrarily sized bit of data, send it". People still need to do `thing.length == 0 ? -1 : thing.length` checks.
* Why would we add something that could be deprecated if we just found the time to reach consensus on the direction of the API?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180951549
More information about the net-dev
mailing list