@karussell successfully tested with all our providers. This should also make elevation handling much more robust. GraphHopper can now be safely stopped during the import phase without corrupting the cache 🙂

Hm, I do not see the benefits here. All the advantages you listed could as well be implemented for HttpURLConnection. Or am I misunderstanding something?

GraphHopper can now be safely stopped during the import phase without corrupting the cache 🙂

Because of storing the data into a .part file first? Wouldn't this work for the old HttpURLConnection too?

Hm, I do not see the benefits here. All the advantages you listed could as well be implemented for HttpURLConnection. Or am I misunderstanding something?

The API is an ugly relic from the Java 1.1 era. The main benefit though is that HttpClient supports HTTP/2 (and even HTTP/3 with Java 26+), which saves bandwidth because they use a binary protocol with header compression. The new client also supports asynchronous calls, if we want to add some kind of prefetching 🙂

GraphHopper can now be safely stopped during the import phase without corrupting the cache 🙂

Because of storing the data into a .part file first? Wouldn't this work for the old HttpURLConnection too?

Sure. I finally managed to pinpoint this bug while testing my HttpClient changes and simply added it as part of this PR 🤷