Consider supporting the new & native `java.net.http` API as a client

commercetools / commercetools-jvm-sdk

The e-commerce SDK from commercetools running on the Java virtual machine.

https://commercetools.github.io/commercetools-jvm-sdk/apidocs/index.html

Other

62 stars 40 forks source link

Consider supporting the new & native `java.net.http` API as a client #1821

Open nkuehn opened 5 years ago

nkuehn commented 5 years ago

Version conflics on apache async HTTP and / or the netty based client are an ongoing chore in projects using the JVM SDK - that's not a commercetools specific problem but a pretty generic one.

I just read that Java 11 has now promoted the JVM-builtin java.net.http API to stable. It's fully asynchronous so it could be okay as an addition (or even default on Java 11+ if no other client is configured).

I haven't fully analyzed or ever used it, that's why this is a "consider" issue only

acbeni commented 5 years ago

Yeah actually i took a look at that and i like that this client comes with java standard packages, but we don't have a plan to migrate to java 11 for the moment especially that this change itself would be breaking for us (since we have to change some packages names + dependencies to have the module structure). So i will leave this issue open, and i ll include it with the blocking label so we might introduce it once we intend to pass to sdk 2.0

butenkor commented 5 years ago

@acbeni I wonder why do you think that we need to do breaking changes? Modularization is optional as far as i know. SDK wrapper of native HTTP client could be supplied as own dependency so new release could work with both Java 8 and Java 11 (if native client has to be used).