upgrade Radiance project to modular project

[jer63]

Version of Radiance : 7.5.0

Sub-project (Common, Animation, Theming)

Version of Java : Java 19

Version of OS : Windows 10

The issue :

Hello,
I'm currently using your Radiance 7.5.0 library in a modular Java 19 project.
I'm opening this incident today to ask you if it's possible to make your Radiance project modular, since it's already compatible with Java > 9. Please add the module-info.java file. This won't change anything for people who don't use modules. If this change is planned for the next version 8.0.0, please let me know the approximate release date.

Best regards,
J. Clos

[kirill-grouchnikov]

Is the a nice to have, or is this blocking the adoption of Radiance in your codebase? It might be nice to have a bit of a stronger way to enforce the distinction of api vs internal packages in Radiance modules, but since Java still (and probably forever) supports the traditional way of jar dependencies, that is not a strong promise.

From my perspective, I'd like to understand the positive outcome of spending time on adding all of that scaffolding.

[jer63]

First of all, I’d like to thank you for your prompt response and for your interest in my request. I’d also like to thank you for all your hard work in developing and maintaining the libraries.

I’ve decided to make my project modular so as to be able to use the new JLink tool. As you probably already know, JLink allows you to generate an installation with an embedded Java machine. The end user no longer has to worry about the version of Java used by the application and check that the Java installed on his or her operating system is compatible with the Java needed to run the application.

This type of installation is very appropriate for the users of my application. These are generally elderly people using the Windows operating system. To install, they simply download a zip file, unzip it to the desired location on the disk and click on the bat command file to launch the application.

JLink requires that the application be modular and that the libraries used by the application be modular as well as the libraries within the libraries. That’s why I’m stuck, because when I generate the version, JLink gives me an error.

When asked about the advantages of passing Radiance libraries as modular, using the export keyword in the module-info.java file, it’s easier to see the problems of dependency between packages from different projects, between the API and internal packages, as you mentioned in your message.

Indeed, the advantages may not be very great for you, but as I explained earlier, this can be a blocking factor for users of your library. What’s more, users of a modular library can use it in a modular context as well as a conventional one.

In the Eclipse environment, you can generate the module-info.java file by right-clicking on a project (configure menu). It will then generate a default file with all the necessary exports.

Best regards,

[kirill-grouchnikov]

sunshine...modularization is about as much time as I'm interested in putting into it. There are two issues, which I looked into for a few hours, and I don't want to spend any more time on. If you have a PR / specific changes that need to be made to address both of these, put them here.

First issue - despite module info being added in the matching modules, Gradle build complains with

/Projects/radiance/common/src/main/java/module-info.java:8: warning: [module] module not found: org.pushingpixels.radiance.theming
        exports org.pushingpixels.radiance.common.internal.contrib.jgoodies.looks to org.pushingpixels.radiance.theming;
                                                                                                               ^

I have the project configured to treat all warnings as errors. There are some SO posts talking about module source path, or some extra project specific flags in the build file. None worked for me. I do not want to remove the -Werror compiler arg to support module info.

The second issue is that Eclipse complains about org.w3c imports needed for SVG related stuff:

Batik and its dependencies are not modularized, and there's some sort of an expectation of the JPMS to have only one module defining the same package. There are some SO posts talking about configuring a dependency to exclude some of its dependencies, but none worked for me.

[jer63]

Hello,
Thank you for taking the time to look at your library’s dependency and modularity issues. Indeed, I went to batik 1.18 and the Batik project is not modular. As a result, you can’t make your project modular if you have a dependency on Batik. Batik itself has dependencies on libraries that are not modular.

If you agree, the only thing I need from you is permission to modify the sources of the Radiance libraries so that I can make them modular, knowing that I have to do the same for the Batik libraries and still other libraries on which Batik depends.

Thank you very much.
All the best,