Skip to content
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

Native Image with GraalVM #169

Open
nomisRev opened this issue Sep 26, 2023 · 3 comments · May be fixed by #183
Open

Native Image with GraalVM #169

nomisRev opened this issue Sep 26, 2023 · 3 comments · May be fixed by #183
Assignees
Labels
hacktoberfest Tickets belonging to hacktoberfest

Comments

@nomisRev
Copy link
Owner

Update the build files, and change the engine (Netty is not supported for GraalVM) such that a docker image can be build with a native image.

Check out:

@nomisRev nomisRev added the hacktoberfest Tickets belonging to hacktoberfest label Sep 26, 2023
@organize
Copy link
Contributor

organize commented Oct 6, 2023

I can take a look at this next 👍

@organize
Copy link
Contributor

organize commented Oct 7, 2023

I have the server running as a native image, but there are some gotchas with GraalVM metadata and serialization.

Ktor's content negotiation still uses reflection as described here and the workaround kinda defeats its purpose entirely. So invoking either call.receive() or call.respond() will lead to runtime exceptions, unless you include every reflectable class in reflect-config.json.

Another thing I ran into is kjwt using kotlinx-serialization internally:

kotlinx.serialization.SerializationException: Serializer for class 'JsonObject' is not found.
Please ensure that class is marked as '@Serializable' and that the serialization compiler plugin is applied.

@organize organize linked a pull request Oct 8, 2023 that will close this issue
@organize
Copy link
Contributor

@nomisRev (re: above) how should I scope this change? I feel like the Ktor workaround (applied in the draft PR) is a bit ugly and the fact that receive() / respond() must be avoided in favour of some homebrew helpers is non-trivial. Maybe 🤔

Another option is to use the @Reflectable annotation where needed, but that's not much better since you still need to remember to do that to avoid runtime surprises.

Do you have any better options in mind? 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hacktoberfest Tickets belonging to hacktoberfest
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants