-
Notifications
You must be signed in to change notification settings - Fork 729
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
feat: GraalVM support #1914
feat: GraalVM support #1914
Conversation
What I did:
Hey @gsmet - it would be very nice if you could check if I missed something in the configs. 😃 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1914 +/- ##
=========================================
Coverage 81.36% 81.36%
Complexity 2464 2464
=========================================
Files 239 239
Lines 7471 7471
Branches 401 401
=========================================
Hits 6079 6079
Misses 1146 1146
Partials 246 246 ☔ View full report in Codecov by Sentry. |
Important: If there are any new classes that requires reflections those need to be added to the configs as well as they are not auto generated via Spring / Quarkus |
d83066b
to
12a5dcc
Compare
I had to force push as I forgot the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klopfdreh
Thanks for giving this a try. This PR avoids the dependency, but it introduces a manual step for any time a class is added or removed. I'm not opposed this outright, but if you're going to go this route, there needs to be a test that checks that all expected classes are present in the file.
@klopfdreh Also, it looks like you're registering all the classes in The difficulty here is that we don't have a way of indicating what classes should and shouldn't be in the file. Added some notes to #1908 just for reference... Here's my thought on how to proceed:
This will ensure the files are maintained but also have low cost to maintain them. How does this sound to you? |
For me this sounds a bit odd that you want to handle both classes with/without reflections, as you already know from the reflect-config.json which classes use them, meaning all others don't use reflection. You can't get a list with classes that require reflection as this is something you need to know and define via spring-aot. I agree that it is much nicer to find out if you missed a class in the reflect-config.json during build time, but the only way to see if it is working is to start a native image in your pipeline (which is expensive). Note: It is not that big of a deal to add all classes to reflect and serialization as it is like in the JVM. The performance impact is also very low (I tested it already). What I suggest would be to add a test that uses spring-aot and checks via Registrar if all classes are mentioned in the reflect-config.json. To use reachable meta data for generating the reflect-config.json is risky as you have to have a 100% test coverage all the time. |
In the Quarkus extension, we have a test that approximates things a bit, meaning we have a list of excluded classes and any time a class gets added, we have to decide if we exclude it or add it: https://github.com/quarkiverse/quarkus-github-api/blob/main/deployment/src/test/java/io/quarkiverse/githubapi/deployment/GitHubApiDotNamesTest.java#L28 . It has worked well enough for us even if not ideal. |
BTW, I still think that having an annotation and an annotation processor would make things a bit easier. People wouldn't have to adjust the JSON file, which can be error prone, they would just have to add an annotation. |
I agree to this suggestion. It is a bit on the bare minimum side, but I would accept this. Can the test also update the json file (and then report failure)? That would address @gsmet's concern about maintaining the json file.
This is basically lines up with what I was thinking around not registering classes for reflection which don't need it. What this test shows is that having an exclude list is not expensive and it lets us check "all classes except a specific list are mentioned in the reflect-config.json". If you're willing to do this @klopfdreh, that would be even better but not absolute required. |
@bitwiseman - I am going to add the test, tomorrow. Even if this is a manual effort to add the entry into the reflect-config.json I would not let a test change the source code. (It is still only a test) |
Then If possible make the output when the test fails clear instructions about what to change. |
cbe105a
to
c1d73b9
Compare
Hey @bitwiseman - I added the test now. Things which are important:
I have Java > 17 installed locally and already tested that if you run
|
d127886
to
61cf034
Compare
61cf034
to
529f044
Compare
0deab6b
to
c35001f
Compare
9f54fc2
to
dd53d7c
Compare
@@ -0,0 +1,91 @@ | |||
org.kohsuke.github.AbuseLimitHandler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not sure this list is correct, but issues here can be addressed as bug fixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klopfdreh
Great work!
@gsmet
This looks good to me. Please review and approve if you agree.
I'm going to merge this. @gsmet if you have any changes, please file an issue and tag @klopfdreh . |
Description
This PR will enable the
github-api
to be supported by GraalVM. There have been two options discussed.@bitwiseman preferred option 2 as it reduces the dependencies and lower the costs.
The See #1908 for more information
Before submitting a PR:
@link
JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .mvn -D enable-ci clean install site
locally. If this command doesn't succeed, your change will not pass CI.main
. You will create your PR from that branch.When creating a PR: