Conversation
|
@MinnDevelopment Hi, do you have any thoughts about this PR? |
|
@mikomikotaishi what about the 100 compiler warnings? |
api/src/main/java/module-info.java
Outdated
| module club.minnced.discord.jdave { | ||
| requires java.base; | ||
| requires transitive net.dv8tion.jda; | ||
| requires org.jspecify; |
There was a problem hiding this comment.
Annotations should not be a required dependency to use this library. I would probably use requires static transitive here
There was a problem hiding this comment.
Ah, good catch, I've also applied requires static for org.jspecify as well because it's for annotations.
|
The README has a section about native access warnings, which need to include a section on how to properly allow access when this is used as a module. Currently, it only specifies it for unnamed modules. Currently, there is no real tests if the library can be loaded properly when modules are used, since the JUNIT tests all use unnamed modules. I assume that it won't work since the library is loaded via |
|
I think the following changes should fix the warnings, which are mostly tied to restricted methods from FFM, |
2 participants
This PR adds a JPMS module, named
club.minnced.discord.jdave.While the project could use automatic modules, considering the project is Java 25 it seems reasonable to implement proper module support for the project, and the list of packages is pretty easy to maintain. (JDA can't be modularised because it has a minimum of Java 8, but it has automatic module support.)
The reason I am hoping to add this is because some tooling fails to find the symbols, and it is better to work using module path than class path when using modular projects.