curl to Java

What this tool is used for

• Converting an API's curl example into OkHttp for a JVM service.
• Reproducing a captured request inside an existing OkHttp client.
• Getting the builder chain right for a request with a body.
• Producing a snippet for a test or a small tool.
• Comparing OkHttp against the built-in HttpClient for one request.

Frequently Asked Questions

Which HTTP client should I target?

java.net.http.HttpClient, standard since Java 11, supports HTTP/2 and async out of the box. The legacy HttpURLConnection still works everywhere but is verbose and awkward for bodies. OkHttp and Apache HttpClient remain common in older codebases.

How do I send a request body?

Through a BodyPublisher: HttpRequest.BodyPublishers.ofString(json) for text, ofFile(path) for uploads, noBody() for GET. The matching BodyHandlers.ofString() on the response side controls how the reply is materialised.

How do I set a timeout?

Two separate settings: HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(10)) for establishing the connection, and .timeout(...) on the individual HttpRequest for the whole exchange. Neither has a default — both are unbounded until set.

Does it follow redirects?

No. HttpClient defaults to Redirect.NEVER, unlike curl -L and unlike most other languages here. Call .followRedirects(HttpClient.Redirect.NORMAL) to follow, which follows except from HTTPS down to HTTP.

How do I make the call asynchronous?

sendAsync() returns a CompletableFuture<HttpResponse<T>>, chainable with thenApply/thenAccept. send() is the blocking form. The same client instance is thread-safe and intended to be shared.

Why is the HttpClient immutable?

Because it is built once and shared safely across threads — there are no setters to race on. Anything per-request, including timeouts on the request rather than the client, goes on the `HttpRequest` builder instead.

What do virtual threads change?

They make the blocking `send` call cheap to scale, since a blocked virtual thread does not hold an OS thread. On a modern JDK that removes most of the reason to reach for `sendAsync` and its `CompletableFuture` chaining.

Common errors and gotchas

• Not closing the response, which leaks connections — OkHttp requires it explicitly.
• Creating a client per request rather than sharing one, which discards the connection pool.
• Forgetting the media type on a request body, which OkHttp will not infer.
• Assuming a non-2xx throws, when you must check `isSuccessful`.
• Reading the body more than once, which OkHttp does not allow.