Integration into java.net.http.HTTPClient

[fabianfrz]

Is your feature request related to a problem? Please describe.

Hi I would like to ask if you could add an integration into java.net.http.HttpClient, which is now available due to the upgrade of the baseline to JDK-17.

It allows using a handler that can be used simmilar to the Jax-RS client, which could make that client a little bit obsolete.

It has two places, where we can serialize and deserialize - on transmit and on receive. The receive part is a little bit more tricky, since APIs could respond with different objects. However when this is the goal, It would be better to not handle this case directly in the client and deserialize afterwards.

Describe the solution you'd like

I made a working prototype here:

https://github.com/fabianfrz/jackson-http-client

I made this work with practically no external dependencies (only junit + mockito) for testing.
However I am not sure how to bring this into the Jackson world. Should there be a different repo, put those classes to core or whatever.

Also I am currently not sure if this should offload data to disk if it is too large and the index of the byte array is limitted to int so the may file size is currently 4GiB in my code.

Usage example

See test classes:

HttpClient httpClient = HttpClient.newBuilder().build(); // create client
        var request = HttpRequest.newBuilder(endpointURI)
            .header("Content-Type", "application/json")
            .POST(new JacksonBodyPublisher<>(data)) // serialize data byte[] and tx it
            .build();
        var response = assertDoesNotThrow(
            () -> httpClient.send(request, new JacksonBodyHandler<>(MockResponse.class)) // deserialize the response body to MockResponse
        );
        assertEquals("Hello World!", response.body().getMessage()); // access the deserialzed body using .body()

Additional context

There is a notable change regarding HTTPClient: in newer JDKs, HTTPClient will implement AutoClosable in newer JDK versions to free up resources early as you can the usage in the tests. So currently I cannot close them with the try-with-resources block which means that the test source may not free up immediately.

[JooHyukKim]

I checked code here, and seems like this new JacksonBodyPublisher() would be intializing ObjectMapper every API call or I read wrong?

[pjfanning]

Better to critique the code in its GitHub project and to use this discussion to be about whether Jackson team takes this over. My personal view is that it can live as an external project and lib. We can see about providing a list of community projects related to Jackson.

[fabianfrz]

no you did not. I did actually not think about it but it would be nice if the Jackson Core would provide a central singleton for this to avoid having multiple instances spread over the code. However I am not aware of any.

However I did add your improvement idea to cache the instance per class.

[cowtowncoder]

Hmmh. Interesting question/idea. Normally I would be of "no, not in core" opinion, but given this only has JDK dependencies, I might be convinced to accept inclusion.
And since there's ObjectMapper (or should that be ObjectReader / ObjectWriters on handlers), it'd probably be in jackson-databind.

But then again, question is that of how to integrate things -- and this does not really fit into "data format" or "data type" or even general JacksonModule packaging. Adding somewhat loose set of classes in databind is not good API design, nor great for discoverability.

We could consider another component, too, but mostly we just have Module repos (plus jaxrs-/jakarta-rs providers) and like I said, these classes cannot really use JacksonModule approach.

So, I don't know yet. We do not seem to have good place to add these in; but I can see value in somehow offering this functionality. Let's keep discussing ideas!

[fabianfrz]

Take the time you need to get a good result.

One thing that would be nice for using Jackson with frameworks especially in the web context would be, if all the ObjectMapper variants could be found using the service loader and all object mapper instances would have a method returning the supported mime types.

This would allow to find and register all of them automatically in probably any client and framework.

But that is not that important for now.