-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
okhttp parse error with GraalVM CE 19.0.0 #1521
Comments
I have a branch I'm poking at for okhttp, using the trivial built in curl command. Mostly working but relies on SunEC native lib. It also works because it hacks the OkHttp interface definitions to include default methods. May not help with this issue, but could help in other ways.
So on the PR, I force the DefaultImpls class to exist by implementing dummy methods on the interfaces. But this is possible when you are directly changing the okhttp codebase. |
Also if this is really blocking you, falling back to okhttp 3.14.2 should work, but you will need to revert some nice kotlin source changes. OkHttp 3.14 is java implemented, while OkHttp 4.0 is kotlin based. |
FWIW I also get the following warnings in output, specifically related to the classes that trigger DefaultImpls errors
|
I got OkHttp working for me end to end by
|
Thanks for all the input @yschimke! I was able to solve the issue by downgrading to 3.14.2. It only required some very minor changes. Pretty much just missing the companion objects. I will keep an eye on the 4.0 branch and if a fix gets pushed, I'll upgrade again. For future reference, what is causing this incompatibility with graal? |
Not sure. I assume kotlin and how it creates interfaces. When you decompile kotlin there is a lot of syntactic sugar to make modern features work down to JDK 1.6. So I think edge cases really. |
@mcred based on the stack trace I think it's issues related to "unknown locality of class" with Kotlin. |
Kotlin issue ticket https://youtrack.jetbrains.com/issue/KT-33097 |
Fixed on okhttp using a workaround described on this ticket |
Thank you, @mageddo! |
This is a different okhttp issue from #1294. The
native-image
compiler fails to parse theOkHttpClient.Builder()
. A sample that recreates the issue is available here. Here is the gist:The sample will compile with the following JRE
Running with java works:
Compiling with
native-image
fails:Stack trace output:
It doesn't look to be a reflection issue. Does anyone have a clue why this is happening?
The text was updated successfully, but these errors were encountered: