Instead we just provide a definition of what we would like to happen when the response is ready and let the CompletableFutures and ForkJoinPool handle getting the work done as quickly as possible. Any time we make a request there might be a delay before the response comes back, and using the CompletionStage API lets us avoid the trap of blocking a thread while waiting for the response. Making HTTP requests is naturally an asychronous business. Additionally, using the ForkJoinPool gives us an excellent work-stealing thread pool for good performance. Callback-style code tends to scatter the actual logic around more than I want. Why CompletionStage?įor me, the biggest appeal of using CompletionStages is to define in a single place a high-level asynchronous workflow. For example you can use this to create a retry mechanism, where you don’t know in advance how many stages you will need. Once the new stage has completed its value is used for thenCompose. Instead of returning a value, the provided Function has to return a CompletionStage which is executed under the same rules as the original CompletionStage. This is a really powerful method, and IMO the hardest to understand. thenCompose ( Function f ( x )-> CompletionStage ) // also has Async versions What you get from j.u.c.FutureĪs with all other Future objects, a CompletableFuture is like a box which will at some point contain the result of an asynchronous action, like this:ĬompletionStage. A CompletableFuture also implements, as added in Java 5. The only implementation is CompletableFuture. The basics: CompletionStage is an interface. In my experience very few Java developers know about it, and even fewer use it, but it’s an very powerful framework for building asynchronous workflows. When Java 8 was released there were a lot of attention-grabbing features such as lambdas and the streams API, so the CompletionStage API is often overlooked. ![]() The CompletionStage API and CompletableFutures Now I’ve baited you this far with talk of HTTP clients I’ll switch over to the CompletionStage API. However, my favourite feature is how asynchronous calls are implemented using CompletableFuture. I particularly like the BodyHandler abstraction and the built-in implementations as it is often the case that you immediately need to parse the body of a response. This is a breath of fresh air compared to the old version isn’t it? ofString ()) // Print the response System. build () // Make the request HttpResponse response = client. ![]() newHttpClient () // Create a request object var request = HttpRequest. ![]() Import .* // Create a client var client = HttpClient. Support for HTTP/1.1, HTTP/2 and WebSockets.getInputStream () // Don't forget to close it LOLĪs you can tell I’m not a huge fan of this 1990s API, so I was glad to see a more modern HTTP client come out of incubation in Java 11, and into the package (and module of the same name). getResponseCode () // Now we've got an InputStream to deal with - BufferedReader and iterate or IOUtils? InputStream response = conn. is this the line that actually causes the request to be made? int responseCode = con. setRequestProperty ( "x-header", "value" ) // So. openConnection () // BTW do we capitalize acronyms or not? // We can only set method, headers, etc _after_ the connection is opened (?!!!!) conn. Create a neat value object which represents a URL URL url = new URL ( "" ) // Open a connection (?!) on the URL (?!!) and _cast_ the response (?!!!) HttpURLConnection conn = ( HttpURLConnection ) url.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |