I think some of the advanced usage of kotlin is tripping up graal. But it seems worthwhile to support particularly in the serverless space.
https://github.com/square/okhttp/pull/5125
Currently failing for me with
$ ./gradlew :okcurl:nativeImage
> Task :okhttp:compileKotlin
e: /Users/yuri/workspace/okhttp/okhttp/src/main/java/okhttp3/internal/Internal.kt: (30, 1): Conflicting overloads: public fun parseCookie(currentTimeMillis: Long, url: HttpUrl, setCookie: String): Cookie? defined in okhttp3.internal in file Internal.kt, public fun parseCookie(currentTimeMillis: Long, url: HttpUrl, setCookie: String): Cookie? defined in okhttp3.internal in file internal.kt
I think these are a recent regression, but probably typical with graal and kotlin and using edge cases. It would be good to get a working build showing it is supported.
I can build OkHttp 3.14.1 based apps with graal, so something here has changed.
Most likely a Kotlin+Graal issue we鈥檙e victim to?
I might try to get
./gradlew :okcurl:nativeImage
building, land that with a separate build that tells us when broken. Useful for testing anyway. Are you ok with that plan?
Sure. I don't know enough about Graal to understand how this will constrain us, or what benefits we gain from it.
It's getting adopted by various frameworks e.g. micronauts, and more relevant for fast startup in FaaS models. Support for it generally is more important than okcurl.
Demonstrable performance on a desktop machine for java okhttp
time okcurl/build/graal/okcurl -Djavax.net.ssl.trustStore=cacerts https://api.twitter.com/robots.txt
# Used for Google app indexing. See https://developers.google.com/app-indexing/webmasters/server
User-agent: Googlebot
Disallow:
User-agent: *
Disallow: /
0.03s user 0.02s system 15% cpu 0.303 total
I think two main impact of not having clean graal support are
1) things don't just work, a lot of errors to workaround. But eventually it does work.
2) Some of the workaround defer work to runtime, and then startup times go from 0.02s to 0.5s etc
Working with some caveats https://github.com/square/okhttp/pull/5294
1) need a directory of external libraries, at minimum
2) Can possibly hackaround and use bouncy castle instead of SunEC
3) Can disable ECC in client
Otherwise it frequently blows up because server negotiates ECC cipher and then client fails.
Most helpful comment
It's getting adopted by various frameworks e.g. micronauts, and more relevant for fast startup in FaaS models. Support for it generally is more important than okcurl.
Demonstrable performance on a desktop machine for java okhttp