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.

Sign up for GitHub

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

Jump to bottom

Some plan to write additional unit tests for the class library need GraalVM Reachability Metadata #1

Open
22 of 29 tasks
linghengqian opened this issue Nov 16, 2022 · 7 comments
Open
22 of 29 tasks

Some plan to write additional unit tests for the class library need GraalVM Reachability Metadata #1

linghengqian opened this issue Nov 16, 2022 · 7 comments
Assignees
@linghengqian
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@linghengqian
Copy link
Owner

linghengqian commented Nov 16, 2022 •
edited

@linghengqian linghengqian changed the title Some plan to write additional unit tests for the class library need Graalvm Reachability Metadata Some plan to write additional unit tests for the class library need GraalVM Reachability Metadata Nov 16, 2022
@linghengqian
Copy link
Owner Author

linghengqian commented Nov 16, 2022 •
edited 

<buildArgs>
    <arg>--initialize-at-run-time=groovy.grape.GrapeIvy</arg>
    <arg>--initialize-at-build-time</arg>
</buildArgs>
  • 5baf428 It shows that it is a stupid thing to try to directly generate GraalVM accessibility metadata for Groovy

@linghengqian linghengqian mentioned this issue Nov 17, 2022
Closed
@linghengqian
Copy link
Owner Author

linghengqian commented Nov 17, 2022 •
edited

  • The sample submission process is as follows
./gradlew scaffold --coordinates io.jsonwebtoken:jjwt-jackson:0.11.5
./gradlew :spotlessApply
./gradlew clean test -Pcoordinates=io.jsonwebtoken:jjwt-jackson:0.11.5

@linghengqian linghengqian mentioned this issue Nov 19, 2022
Closed
@linghengqian linghengqian added documentation Improvements or additions to documentation enhancement New feature or request labels Nov 19, 2022
@linghengqian linghengqian self-assigned this Nov 19, 2022
@linghengqian
Copy link
Owner Author

linghengqian commented Nov 20, 2022 •
edited

  • Considering that libraries like vertx-core need more unit tests, I have to go to the main branch of vertx-core for testing. Modify pom.xml, native/access-filter.json, native/caller-filter.json and native/user-code-filter.json, there are the following steps.
mkdir -p src/main/resources/META-INF/native-image/io.vertx/vertx-core
mvn clean test -Pnative -Dagent=true -Dmaven.test.failure.ignore=true -Djacoco.skip=true
native-image-configure generate-conditional --user-code-filter=native/user-code-filter.json --input-dir=target/native/agent-output/test/session-1372021-20221119T230740Z --output-dir=src/main/resources/META-INF/native-image/io.vertx/vertx-core

@linghengqian linghengqian mentioned this issue Nov 21, 2022
Closed
@linghengqian
Copy link
Owner Author

@linghengqian linghengqian added the good first issue Good for newcomers label Nov 23, 2022
This was referenced Nov 23, 2022
Closed
Closed
@linghengqian linghengqian mentioned this issue Dec 1, 2022
Closed
@linghengqian linghengqian removed the good first issue Good for newcomers label Dec 1, 2022
This was referenced Dec 2, 2022
Open
Closed
Open
@linghengqian
Copy link
Owner Author

linghengqian commented Dec 14, 2022 •
edited

  • With truffle, I was able to single test nativeTest under my single test in a heterogeneous language such as javascript. I can even imagine adding spi to a ShardingSphere's actualdatanode to execute a js segment on an implementation so that it runs nativeTest. This is hard coupled to the graalvm sdk's maven dependency. 🌝 But I couldn't get through GroovyShell-related unit tests using truffle's espresso run, which picocli nearly did with its pr a few years ago. The result is a straightforward disregard of groovyshell's operations under graalvm native images 🤔. Refer to [GR-43010] Using Groovy classes under native-image results in UnsupportedFeatureError oracle/graal#5522 .

  • With truffle, other than jvm languages (obviously I'm talking about both java and groovy🌿), graalvm native image behaves just fine... Whether it's javascript, python, or ruby. So abstract.

  • No one in groovy seems to have touched truffle, @virtualdogbert discusses some very old stuff (like micronant playing in espresso before 100% jdk tck pass phase). @Alfonso Peterssen successfully tested on internal systems last year host java interworks with guest groovy in the espresso api, but context#eval cannot be used in current espresso at all. graalvm native image also doesn't seem to have the unknown option of --language:groovy. Refer to https://groovy-community.slack.com/archives/C2NEFCM55/p1670101822262799?thread_ts=1670101822.262799&cid=C2NEFCM55 and https://graalvm.slack.com/archives/CPSD12R71/p1627671413006000?thread_ts=1627671413.006000&cid=CPSD12R71 .

  • Every time I saw the key point of the issue, an oracle internal tracking number (GR-xxxxx👉🌿) popped up. I wasn't sure how I could change the single test in shardingsphere to look like nativeTest pass. espresso's roadmap on groovy was a bit of a collaboration with the groovy community, but the biggest intersection I saw over the next year was a new project under graalvm moving from maven to gradle. 🙊

  • When I played with org.graalvm.truffle:truffle-api:22.3.0, I thought that ASF did not limit the use of UPL LICENSE components in binary at https://www.apache.org/legal/resolved.html, but I seem to be from Haven't seen a project that actually has this type of component...? 👀

This was referenced Dec 15, 2022
Closed
Open
@linghengqian linghengqian mentioned this issue Dec 23, 2022
Closed
@tiro8183 tiro8183 mentioned this issue Dec 26, 2022
Open
This was referenced Jan 5, 2023
Closed
Closed
Closed
Closed
Closed
@linghengqian linghengqian mentioned this issue Jan 13, 2023
Open
5 tasks
This was referenced Jan 14, 2023
Closed
Closed
This was referenced Jan 23, 2023
Closed
Closed
Closed
Open
Open
Closed
This was referenced Feb 6, 2023
Closed
Closed
Closed
@linghengqian
Copy link
Owner Author

linghengqian commented Feb 7, 2023 •
edited

Yes, we're also looking into agent support.
Agents that manipulate bytecode should be easy to support as NI operates on bytecode.
Other agents may be harder, but not impossible to support.
vojjovmay have more details.

And don't worry, I know you're supportive!
I'd just like to make sure the community isn't misinformed: just because NI doesn't support something today doesn't mean it can't in the future.

There's still plenty of work ahead of us.
I would say that JVMTI agents are unlikely in the near future.
Also, it is questionable how much of the JVMTI would make sense in the case of Native Image as there are significant differences in behavior (e.g., class loading).

For Java agents, they should work now as long as you don't modify the code executed at build time (e.g., JDK and the Native Image itself) in ways that would not work on the machine that does the image build.

If we guard generated code that is executed at build time with ImageInfo.inImageRuntimeCode() all should work. Happy to help with concrete cases over our slack channel.

@linghengqian linghengqian pinned this issue Feb 8, 2023
@linghengqian linghengqian mentioned this issue Feb 11, 2023
Open
@linghengqian linghengqian mentioned this issue Sep 6, 2023
Closed
@linghengqian linghengqian unpinned this issue Sep 11, 2023
@linghengqian
Copy link
Owner Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@linghengqian linghengqian

Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@linghengqian