3 ms·

Your java knowledge is outdated. Java's JDK has a nice, modern HTTP Client https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpCl

by lenkite 7mo ago

Your java knowledge is outdated. Java's JDK has a nice, modern HTTP Client https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html https://docs.oracle.com/en/java/javase/11/docs/api/java.net....

ffsm8 7mo ago
Ahh, java. You never change, even if you're modern HttpClient client = HttpClient.newBuilder() .version(Version.HTTP_1_1) .followRedirects(Redirect.NORMAL) .connectTimeout(Duration.ofSeconds(20)) .proxy(ProxySelector.of( new InetSocketAddress("proxy.example.com", 80) )) .authenticator(Authenticator.getDefault()) .build(); HttpResponse<String> response = client.send(request, BodyHandlers.ofString()); System.out.println(response.statusCode()); System.out.println(response.body()); For the record, you're most likely not even interacting with that API directly if you're using any current framework, because most just provide automagically generated clients and you only define the interface with some annotations
- awkwardpotato 7mo ago
  What's the matter with this? It's a clean builder pattern, the response is returned directly from send. I've certainly seen uglier Java
  - PxldLtd 7mo ago
    Yeah this is all over Rust codebases too for good reason. The argument is that default params obfuscate behaviour and passing in a struct (in Rust) with defaults kneecaps your ability to validate parameters at compile time.
    - Pay08 7mo ago
      It does have defaults, the above example manually sets everything to show people reading the docs what that looks like.
  - colejohnson66 7mo ago
    The boilerplate of not having sane defaults. .NET is much simpler: using HttpClient client = new(); HttpResponseMessage response = await client.GetAsync("https://..."); if (response.StatusCode is HttpStatusCode.OK) { string s = await response.Content.ReadAsStringAsync(); // ... }
    - lmz 7mo ago
      That's just an example. It does have defaults: https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.Builder.html https://docs.oracle.com/en/java/javase/11/docs/api/java.net.... (search for "If this method is not invoked")
    - pjmlp 7mo ago
      Yeah, so much simpler, "Common IHttpClientFactory usage issues" https://learn.microsoft.com/en-us/dotnet/core/extensions/httpclient-factory-troubleshooting https://learn.microsoft.com/en-us/dotnet/core/extensions/htt... "Guidelines for using HttpClient" https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/httpclient-guidelines?source=recommendations https://learn.microsoft.com/en-us/dotnet/fundamentals/networ... And this doesn't account for all gotchas as per .NET version, than only us old timers remember to cross check.
      - colejohnson66 7mo ago
        I didn't mention IHttpClientFactory - just HttpClient. I will concede that ASP manages to be confusing quite often. As for the latter, guidelines are not requirements anymore than "RTFM" is; You can use HttpClient without reading the guidelines and be just fine.
        pjmlp 7mo ago
        For various outcomes of fine, depending on .NET version, given that not everyone is on very latest.
  - freedomben 7mo ago
    Just my opinion of course, but: > What's the matter with this? To me what makes this very "Java" is the arguments being passed, and all the OOP stuff that isn't providing any benefit and isn't really modeling real-world-ish objects (which IMHO is where OOP shines). .version(Version.HTTP_1_1) and .followRedirects(Redirect.NORMAL) I can sort of accept, but it requires knowing what class and value to pass, which is lookups/documentation reference. These are spread out over a bunch of classes. But we start getting so "Java" with the next ones. .connectTimeout(Duration.ofSeconds(20)) (why can't I just pass 20 or 20_000 or something? Do we really need another class and method here?) .proxy(ProxySelector.of(new InetSocketAddress("proxy.example.com", 80))), geez that's complex. .authenticator(Authenticator.getDefault()), why not just pass bearer token or something? Now I have to look up this Authenticator class, initialize it, figure out where it's getting the credentials, how it's inserting them, how I put the credentials in the right place, etc. The important details are hidden/obscured behind needless abstraction layers IMHO. I think Java is a good language, but most modern Java patterns can get ludicrous with the abstractions. When I was writing lots of Java, I was constantly setting up an ncat listener to hit so I could see what it's actually writing, and then have to hunt down where a certain thing is being done and figuring out the right way to get it to behave correctly. Contrast with a typical Typescript HTTP request and you can mostly tell just from reading the snippet what the actual HTTP request is going to look like.
    - Pay08 7mo ago
      > why can't I just pass 20 or 20_000 or something? Do we really need another class and method here? If you've ever dealt with time, you'll be grateful it's a duration and not some random int.
    - looperhacks 7mo ago
      > but it requires knowing what class and value to pass Unless you use a text editor without any coding capabilities, your IDE should show you which values you can pass. The alternative is to have more methods, I guess? > why can't I just pass 20 or 20_000 or something 20 what? Milliseconds? Seconds? Minutes? While I wouldn't write the full Duration.ofSeconds(20) (you can save the "Duration."), I don't understand how one could prefer a version that makes you guess the unit. > proxy(ProxySelector.of(new InetSocketAddress("proxy.example.com", 80))), geez that's complex Yes it is, can't add anything here. There's a tradeoff between "do the simple thing" and "make all things possible", and Java chooses the second here. > .authenticator(Authenticator.getDefault()), why not just pass bearer token or something? Because this Authenticator is meant for prompting a user interactively. I concur that this is very confusing, but if you want a Bearer token, just set the header.
  - zahlman 7mo ago
    > What's the matter with this? It's a clean builder pattern I feel like you answered yourself. Java makes you do this by not supporting proper keyword arguments.
- lenkite 7mo ago
  Your http client setup is over-complicated. You certainly don't need `.proxy` if you are not using a proxy or if you are using the system default proxy, nor do you need `.authenticator` if you are not doing HTTP authentication. Nor do you need `version` since there is already a fallback to HTTP/1.1. HttpClient client = HttpClient.newBuilder() .followRedirects(Redirect.NORMAL) .connectTimeout(Duration.ofSeconds(20)) .build();
  - ffsm8 7mo ago
    It was literally just copy pasted from the linked source (the official Oracle docs)
    - Tostino 7mo ago
      And those docs were likely trying to show you how to use multiple features, not the most basic implementation of it
      - ffsm8 7mo ago
        I mean dont get me wrong, I work with Java basically 8 hours per day. I also get _why_ the API is as it is - It essentially boils down to the massive Inversion of Control fetish the Java ecosystem has. It does enable code that "hides" implementation very well, like the quoted examples authentication API lets you authenticate in any way you can imagine, as in literally any way imaginable. Its incredibly flexible. Want to only be able to send the request out after you've touched a file, send of a Message through a message broker and then maybe flex by waiting for the response of that async communication and use that as a custom attribute in the payload, additionally to a dynamically negotiated header to be set according to the response of a DNS query? yeah, we can do that! and the caller doesnt have to know any of that... at least as long as it works as intended Same with the Proxy layer, the client is _entirely_ extensible, it is what Inversion of Control enables. It just comes with the unfortunate side-effect of forcing the dev to be extremely fluent in enterprisey patterns. I dont mind it anymore, myself. the other day ive even implemented a custom "dependency injection" inspired system for data in a very dynamic application at my dayjob. I did that so the caller wont even need to know what data he needs! it just get automatically resolved through the abstraction. But i strongly suspect if a jr develeoper which hasnt gotten used to the java ecosystem will come across it, he'll be completely out of his depth how the grander system works - even though a dev thats used to it will likely understand the system within a couple of moments. Like everything in software, everything has advantages and disadvantages. And Java has just historically always tried to "hide complexity", which in practice however paradoxically multiplies complexity _if youre not already used to the pattern used_.

by lenkite 7mo ago

ffsm8 7mo ago

Ahh, java. You never change, even if you're modern HttpClient client = HttpClient.newBuilder() .version(Version.HTTP_1_1) .followRedirects(Redirect.NORMAL) .connectTimeout(Duration.ofSeconds(20)) .proxy(ProxySelector.of( new InetSocketAddress("proxy.example.com", 80) )) .authenticator(Authenticator.getDefault()) .build(); HttpResponse<String> response = client.send(request, BodyHandlers.ofString()); System.out.println(response.statusCode()); System.out.println(response.body()); For the record, you're most likely not even interacting with that API directly if you're using any current framework, because most just provide automagically generated clients and you only define the interface with some annotations

awkwardpotato 7mo ago
What's the matter with this? It's a clean builder pattern, the response is returned directly from send. I've certainly seen uglier Java
- PxldLtd 7mo ago
  Yeah this is all over Rust codebases too for good reason. The argument is that default params obfuscate behaviour and passing in a struct (in Rust) with defaults kneecaps your ability to validate parameters at compile time.
  - Pay08 7mo ago
    It does have defaults, the above example manually sets everything to show people reading the docs what that looks like.
- colejohnson66 7mo ago
  The boilerplate of not having sane defaults. .NET is much simpler: using HttpClient client = new(); HttpResponseMessage response = await client.GetAsync("https://..."); if (response.StatusCode is HttpStatusCode.OK) { string s = await response.Content.ReadAsStringAsync(); // ... }
  - lmz 7mo ago
    That's just an example. It does have defaults: https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.Builder.html https://docs.oracle.com/en/java/javase/11/docs/api/java.net.... (search for "If this method is not invoked")
  - pjmlp 7mo ago
    Yeah, so much simpler, "Common IHttpClientFactory usage issues" https://learn.microsoft.com/en-us/dotnet/core/extensions/httpclient-factory-troubleshooting https://learn.microsoft.com/en-us/dotnet/core/extensions/htt... "Guidelines for using HttpClient" https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/httpclient-guidelines?source=recommendations https://learn.microsoft.com/en-us/dotnet/fundamentals/networ... And this doesn't account for all gotchas as per .NET version, than only us old timers remember to cross check.
    - colejohnson66 7mo ago
      I didn't mention IHttpClientFactory - just HttpClient. I will concede that ASP manages to be confusing quite often. As for the latter, guidelines are not requirements anymore than "RTFM" is; You can use HttpClient without reading the guidelines and be just fine.
      - pjmlp 7mo ago
        For various outcomes of fine, depending on .NET version, given that not everyone is on very latest.
- freedomben 7mo ago
  Just my opinion of course, but: > What's the matter with this? To me what makes this very "Java" is the arguments being passed, and all the OOP stuff that isn't providing any benefit and isn't really modeling real-world-ish objects (which IMHO is where OOP shines). .version(Version.HTTP_1_1) and .followRedirects(Redirect.NORMAL) I can sort of accept, but it requires knowing what class and value to pass, which is lookups/documentation reference. These are spread out over a bunch of classes. But we start getting so "Java" with the next ones. .connectTimeout(Duration.ofSeconds(20)) (why can't I just pass 20 or 20_000 or something? Do we really need another class and method here?) .proxy(ProxySelector.of(new InetSocketAddress("proxy.example.com", 80))), geez that's complex. .authenticator(Authenticator.getDefault()), why not just pass bearer token or something? Now I have to look up this Authenticator class, initialize it, figure out where it's getting the credentials, how it's inserting them, how I put the credentials in the right place, etc. The important details are hidden/obscured behind needless abstraction layers IMHO. I think Java is a good language, but most modern Java patterns can get ludicrous with the abstractions. When I was writing lots of Java, I was constantly setting up an ncat listener to hit so I could see what it's actually writing, and then have to hunt down where a certain thing is being done and figuring out the right way to get it to behave correctly. Contrast with a typical Typescript HTTP request and you can mostly tell just from reading the snippet what the actual HTTP request is going to look like.
  - Pay08 7mo ago
    > why can't I just pass 20 or 20_000 or something? Do we really need another class and method here? If you've ever dealt with time, you'll be grateful it's a duration and not some random int.
  - looperhacks 7mo ago
    > but it requires knowing what class and value to pass Unless you use a text editor without any coding capabilities, your IDE should show you which values you can pass. The alternative is to have more methods, I guess? > why can't I just pass 20 or 20_000 or something 20 what? Milliseconds? Seconds? Minutes? While I wouldn't write the full Duration.ofSeconds(20) (you can save the "Duration."), I don't understand how one could prefer a version that makes you guess the unit. > proxy(ProxySelector.of(new InetSocketAddress("proxy.example.com", 80))), geez that's complex Yes it is, can't add anything here. There's a tradeoff between "do the simple thing" and "make all things possible", and Java chooses the second here. > .authenticator(Authenticator.getDefault()), why not just pass bearer token or something? Because this Authenticator is meant for prompting a user interactively. I concur that this is very confusing, but if you want a Bearer token, just set the header.
- zahlman 7mo ago
  > What's the matter with this? It's a clean builder pattern I feel like you answered yourself. Java makes you do this by not supporting proper keyword arguments.
lenkite 7mo ago
Your http client setup is over-complicated. You certainly don't need `.proxy` if you are not using a proxy or if you are using the system default proxy, nor do you need `.authenticator` if you are not doing HTTP authentication. Nor do you need `version` since there is already a fallback to HTTP/1.1. HttpClient client = HttpClient.newBuilder() .followRedirects(Redirect.NORMAL) .connectTimeout(Duration.ofSeconds(20)) .build();
- ffsm8 7mo ago
  It was literally just copy pasted from the linked source (the official Oracle docs)
  - Tostino 7mo ago
    And those docs were likely trying to show you how to use multiple features, not the most basic implementation of it
    - ffsm8 7mo ago
      I mean dont get me wrong, I work with Java basically 8 hours per day. I also get _why_ the API is as it is - It essentially boils down to the massive Inversion of Control fetish the Java ecosystem has. It does enable code that "hides" implementation very well, like the quoted examples authentication API lets you authenticate in any way you can imagine, as in literally any way imaginable. Its incredibly flexible. Want to only be able to send the request out after you've touched a file, send of a Message through a message broker and then maybe flex by waiting for the response of that async communication and use that as a custom attribute in the payload, additionally to a dynamically negotiated header to be set according to the response of a DNS query? yeah, we can do that! and the caller doesnt have to know any of that... at least as long as it works as intended Same with the Proxy layer, the client is _entirely_ extensible, it is what Inversion of Control enables. It just comes with the unfortunate side-effect of forcing the dev to be extremely fluent in enterprisey patterns. I dont mind it anymore, myself. the other day ive even implemented a custom "dependency injection" inspired system for data in a very dynamic application at my dayjob. I did that so the caller wont even need to know what data he needs! it just get automatically resolved through the abstraction. But i strongly suspect if a jr develeoper which hasnt gotten used to the java ecosystem will come across it, he'll be completely out of his depth how the grander system works - even though a dev thats used to it will likely understand the system within a couple of moments. Like everything in software, everything has advantages and disadvantages. And Java has just historically always tried to "hide complexity", which in practice however paradoxically multiplies complexity _if youre not already used to the pattern used_.