Closed nicolabeghin closed 5 years ago
Hi there! I'm the primary person maintaining and I am focused on Android which brings with it the mostly-horrible requirement that I even work on java7 (!). But I forked off compatibility there so we could adopt Java 8 features that came in a PR, so there is track record with me and this library moving into newer APIs. I am not personally motivated to code them up but I am happy to collaborate on reviewing any sort of PR that comes in and seems to show a benefit by using the new features. If there is a built in client that doesn't suck (like the ones in the past did - why I started maintaining this code in the first place! to get okhttp), adding optional support for it would be fine by me, pending a look at what the change looked like. I will say that I don't see a problem with okhttp personally - so there may be a higher bar here, but maybe just to keep your size down or something, I see motivation for others
That's all so wishy-washy, sorry. But hopefully makes sense
hi @mikehardy, totally understand being an Android developer myself! I just wanted to understand if there was any idea floating around. It could even make sense to wait for OkHttp3 to handle Java11 java.net.http
itself (don't even know if this makes sense at all). thanks!
Hi everyone thanks a lot for the great work maintaining this little gem! I'm currently moving over to "modern" Java, up to Java 12. Any plan or idea on how to support the standard
java.net.http
client now included in the JDK?thanks a lot nicola