Java 9 Modules - #91

or could you walk me though getting the publish to maven local to work so I can test.

Try to comment out those lines
https://github.com/SpaiR/imgui-java/blob/master/publish.gradle#L61-L66

This will take some additional work due to the overlapping package names. I'll see what I can put together.

@SpaiR I have an initial implementation of the library with java 9 modules implemented. This will take some discussion and review, so I will leave it as a draft for now.

Things I had to change to be module compliant:

• Minimum supported java version is now 11. This could have been set to 9, but since 9 is not a LTS that is probably not a good idea.
• Compilation required jdk 17. The source target is still 11, but jdk 17 has key bug fixes in the compiler that make java modules actually possible to compile without a pile of workarounds.
• A modules top level folder must be named after the module, this required me to rename each of the folders. For the sake of managing build tools and for future support, I moved all jms modules into the modules folder. This is handy as for multi-module builds you can simply specify the module path as modules/*. Currently the project is not doing multi-module builds, but if you ever wanted to perform an aggregated javadoc, then this is required.
• Modified classpath. I made the classpath reflective of the module. This is not absolutely required, but makes life much simpler, especially for developers when trying to figure out what module they need to be dependent on.

Key points here are how this breaks backwards compatibility:

• Classpath has changed
• New java minimum version is 11

Everything else is just moving things into the correct folders for java modules.

Screencap of it running on java 11 with modules:

Natives build fine locally for me, I'll investigate why github actions for those are failing.
There may be github links that I have not updated yet, if you find any let me know.
Please do a review and let me know what you think. This is a very large PR with large consequences.

@tlf30 Right now I'm away from the PC, so I did a brief review from the phone to stay in connect.
In technical aspects everything is fine. The main concern is that those changes break compatibility with Java 8 and do a lot of major changes in general. The first point is critical, since even in my workplace we still do use a java 8.
The preferable way will be to do a multi-target release, with a separate packages for jdk8 and jdk11.
I'm okay with that idea in general, sooner or later a migration will be need to be done. For now I'm not sure how soon I'll be able to find a time for that. You can keep the PR opened, I'll look into it later for sure. Or you can also try to tweak a publish config to support muli-tartget release. That will help a lot.

I will see that I can do about a multi-target release. It may be difficult to get working as gradle does a lot of "magic" when it sees the module-info.java file.

The change in the package names will be also break backward compatibility, but I think will be important moving forward as more of the security model becomes based on the package name.

Let's leave this open, I figured this would be a large discussion that will evolve this PR.

Does it compile and work correctly for you?
I can't get it to compile and I would love to use the java 9 module version because of jlink.
I am using Java 17 Temurin and the MSYS2 MINGW64 Shell as recommended.

Does it compile and work correctly for you? I can't get it to compile and I would love to use the java 9 module version because of jlink. I am using Java 17 Temurin and the MSYS2 MINGW64 Shell as recommended.

At the moment you can observe that the PR has a lot of merge conflicts. To proceed with a build you need to address them manually. Changes themselves are correct - you can check the latest "checks" for the PR, they finished successfully.

Hello @Frooastside I can confirm this does indeed compile. If you are having build issues please post the error you are getting.

As a note: I would recommend against using this branch in any project. This is a proof of concept implementation and the final implementation may be very different. Also note that the master branch has significant updates that you will probably want in any project using imgui-java.

@tlf30 Ok got it to compile finally. I think I pulled the submodules before I switched to this branch. Is there anything I can do to get this done faster? I've read that it is not clear if it will be merged because of the missing backward compatibility, even if I solve all merge conflicts, right?

That is correct. I have begun outlining how to do this without changing the package names and using automatic modules instead. At this point, I can keep the package names the same, but a single internal package has to get renamed, which should not impact anyone using the library, and will ensure backwards compatibility. It does require the restructuring of the project into the modules folder just like this branch.

Perhaps when I get off work this evening I can look at getting a PR together that will use automatic modules.

If I need any assistance I will reach out. I work at a remote camp in the artic and do 12 to 14 hour days. I work 2 weeks on and 2 weeks off, I get to go home on Tuesday next week. So in the meantime I am a bit time limited. With that said, I will see what I can get pulled together.

Hello, please see #105 . If that gets merged in I will close this merge request. I will NOT delete this branch from my repo though as it will act as a good go by for once modules are fully implemented in this library.

Closing as #105 is merged. I will keep the branch for reference for when we fully implement modules.