Rob Spoor

Niko Wild wrote:Then scroll down a bit to

Practical Guide – Implementing Chunked Upload in OkHttp
Step-by-Step Implementation of Chunked Upload

The entire word "multipart" is not found on the page you linked to.
The word "multi" is found once: "multiple small chunks". That's not the same as multipart.
The word "address" is found once: the address at the bottom left.

So while chunking may or may not be possible option, multipart requests, mostly through multipart/form-data, is not a (good) option. It only adds more work to split up the file into chunks manually, only to send them again in the same (chunked or not) request.

What you link to is not about multipart requests, it's about chunked data transfers. For both the client and the server it's still one request, they just don't know the size up-front, and the data is best handled in a streaming way.

A multipart request won't help here. That allows you to send multiple parts in a single request, where each part can be a file or text. But if you're uploading all chunks in one request, it's nonsense to use multipart - just upload the file as a single blob.

I was thinking about something similar. I'd probably turn the save action into a POST though, as I'd let it clean-up the chunks if successful, thereby making it non-idempotent: at the end the upload session wouldn't exist anymore.
I'd also let it fail with a 400 or 409 if not all chunks were uploaded successfully, or if there was a checksum mismatch.

Welcome to the Ranch!

I've had this book on my shelf for years, and it's still relevant: Java Concurrency in Practice. Its author, Brian Goetz, is one of the chief architects at Oracle.

You're comparing apples and oranges. There's already quite some overhead when using Integer instead of int because of auto-unboxing. If I change the int[] into an Integer[] the array speedup is around 1, sometimes even less than 1 meaning they have equivalent performances.

Before Java 8 the list sorting would have been worse though, because Collections.sort always called list.toArray() first. It now delegates to list.sort(null) which by default calls this.toArray() but ArrayList has overridden it to directly delegate to Arrays.sort.

That any looks better than my len because it probably allows short-circuiting. The only thing that you're missing is the case-insensitive matching:
any(item.lower() in myUrl.lower() for item in ["url1", "url2", "url3"]) # returns True or FalseThe first lower() can be omitted if the list is fixed and only contains lower case values.

I'm not a Python expert so I don't know if the matching can be improved, but the following works:
len([x for x in ["forums", "scripts", "feedback"] if x.lower() in my_url.lower()]) > 0

You're welcome.

CompletableFuture is a class that implements interface CompletionStage. That means that anything you can do with CompletionStage, you can also do with CompletableFuture. However, CompletableFuture has some methods that aren't in CompletionStage. For instance, join() or getNow(T). For a complete list, check out the non-static methods and check for those that don't include "Specified by".

I don't really see a reason for completedStage (or failedStage. I guess they can be useful if you don't want the object to contain any of the methods of CompletableFuture, because the returned instance cannot be cast to it, but again - I don't see any reason for that.

javax.xml.namespace isn't part of JAXB, it's part of the JSE java.xml module. Still, that doesn't prevent libraries from including the API. For instance, xmlsec 1.5.8 included javax.xml.crypto which is part of the java.xml.crypto module. I remember this one well because it's given me quite a lot of class loading errors in the past.

One of your dependencies is not doing things the right way. Instead of depending on the code provided by the JDK/JRE, they added their own version of the javax.xml.namespace package. What you need to do is figure out which one (your IDE usually lets you browse inside the dependencies), and see if you can upgrade or replace that dependency.

Probably the dependencies. If you include this as dependency, all of its dependencies are automatically included in your project.

Piet Souris wrote:Thanks for the responses, guys!

@Rob,

problem with "? extends Collection<T>"is that I need to do a map.get(t) somewhere, and there I need to specify some type.

I think that you can just use Collection<T> for that.

Untested:
public static <T> Set<Set<T>> getFullConnectedSubsets2(Map<T, ? extends Collection<T>> map) {    var result = new HashSet<Set<T>>();    for (var s: map.keySet()) {        var set = new HashSet<T>();        set.add(s);        gFCSHelper2(map, result, set, map.get(s)); // map.get(s) is (assignable to) Collection<T>    }    return result; } private static <T> void gFCSHelper2(        Map<T, ? extends Collection<T>> map,        Set<Set<T>> result,        Set<T> sofar,        Collection<T> candidates    ) {    if (candidates.isEmpty()) {        result.add(new HashSet<>(sofar));        return;    }    for (var c: candidates) {        sofar.add(c);        var temp = map.get(c);        temp.removeAll(sofar);        var cand = new HashSet<>(candidates);        cand.retainAll(temp);        gFCSHelper2(map, result, sofar, cand); // no cast needed, cand is HashSet<T> which is assignable to Collection<T>        sofar.remove(c);    } }

Piet Souris wrote:edit:
found the solution. I must use
public static <T, S extends Collection<T>> Set<Set<T>> getFullConnectedSubLists(Map<T,S> map) {...}
Never too old to learn.

There's another way that also makes the map's value type not-Collection-but-compatible-with:
public static <T> Set<Set<T>> getFullConnectedSubLists(Map<T, ? extends Collection<T>> map) {...}