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