Okhttp: Support building with graal

Created on 25 May 2019  路  8Comments  路  Source: square/okhttp

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
enhancement

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

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

All 8 comments

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.

Was this page helpful?
0 / 5 - 0 ratings