I don’t wish to derail this thread, so further discussion of java modules should probably be in its own thread. With that said, I did quite a bit of work on a local branch a couple years ago to see just how painful it would be, and it was becoming quite painful. Due to how JME is organized at first glance it looks easy to implement modules, but several key architectural designs will require some key thought on the matter:
Rules JME Breaks for Java Modules:
- No two modules can contain the same classpath. This will be the largest issue to face.
1.5. Because two modules cannot share the same classpath, a protected class within a module cannot be accessed by another module. - No two jars may be the same module: This will be a tricky one that could be worked around. But would require some thought for modules like jme-lwjgl vs jme-lwjgl3.
- Many gradle projects that are multi-module place modules in a directory (usually called modules) and not at the root of the project. This has to do with how jdk tools handles passing module source code as command line arguments. IIRC, I think this is no longer an issue, but I don’t recal if the javadoc generator ever got its’ command line arguments fixed for this.
As stated, further discussion for java modules should get moved elsewhere. @sailsman63 if you are interested in implementing modules, I can be a resource for you, as I have implemented them for several other open source projects and many closed source projects for my company. Unfortunately, I do not have the bandwidth to propose a PR myself, but I am more than happy to answer questions and help whoever wants to try and tackle this. Just note, whoever does try to tackle this will probably be faced with technical issues that need to be resolved (that require breaking changes).