Use java module-info to improve visibility validation of java packages

[planetf1]

During egeria development there have been a variety of cases where one java class has used another it rather shouldn't - breaking the intended 'architecture'.

Sometimes this is noticed when reviewing maven dependencies - especially as we now have additional checks.

Java 9 added modularity support to the language.

For example see the tutorial at https://www.baeldung.com/java-9-modularity

We could use this approach to more precisely define the provider/consumer relationship between our packages (or technically what we would now call modules)

Though egeria still has Java 8 as a minimum level, the package-info file will simply not have any effect in Java 8. But since our builds, including verification, require java 11 to pass also, we should benefit from the checks.

We may not benefit from any checks at runtime if using java 8, but this could bring us significant benefits.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[planetf1]

This could give us extra architectural verification & spot misuse much earlier in the cycle than currently. This will probably reduce any follow on build/compatabilty/packaging issues. It could therefore be a useful investment, in particular at the inner layers of the stack @mandy-chessell

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[planetf1]

See also https://www.pluralsight.com/guides/getting-started-with-the-java-platform-module-system-part-3

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[planetf1]

Related tool (gradle) : https://github.com/jjohannes/extra-java-module-info

[planetf1]

Also https://github.com/jjohannes/java-module-dependencies

[planetf1]

YouTube video: https://www.youtube.com/watch?v=0xijKEeb5ug&list=PLPZy-hmwOdEWUR5OaOGs863rNS2DaIyXS&index=2

[planetf1]

IntelliJ has support for adding module definitions (alternatively this can be done at the command line with jdeps).

• Load up egeria in the latest verison of IntelliJ (v4, gradle build)
• Ensure the latest java 17 compiler is being used, and the language level is set to 17
• Select the top level egeria directory
• Go to Menu->Code->Generate module-info descriptors

IntelliJ will then build, scan, reindex & create the module-info files based on the current packaging

[planetf1]

Mostly clean, though notices this

It's important to bear in mind that the generated files reflect what is being used, and should then be reviewed for intent

[planetf1]

A gradle build will then fail, for example:

We'll see a contextual fix option:

Running a build with ./gradlew clean build --no-build-cache --continue game 165 errors, but only across ~4 projects:

So we end up with lots of definitions such as:

So what this gives us:

• protection against unexpected usage/changes in use
• clarity on current dependencies and consumers
• ability to review these contracts for correctness

But:

• potential pain in updating contracts (but could be a good thing)
• much is restating what we have in our gradle dependencies, but with additional enforcement at the language level
• need to test out to see runtime/packaging impact + on clients/other repos

Suggest discussing this as part of our version 4 plans

[planetf1]

See also:

• https://www.oracle.com/uk/corporate/features/understanding-java-9-modules.html
• https://medium.com/javarevisited/9-things-you-should-know-about-java-modules-43dd5fdeea6

[planetf1]

An initial PR has been created for 'demonstration'. It includes more package renames then required, and inclusion should wait a proper review/agreement at our face to face meeting.

The code basically runs, but some more work is needed on test classes to complete the work

[planetf1]

Agreed in face 2 face meeting Jan 2023 that this was something we should do, but we would not target 4.0. Rather we'd ensure the transition to java / gradle / v4 is smooth and understood first.

Module support can be added incrementally, and in any case remains under control of the consumer, so it is not a change requiring a major release.