Set an automatic module (JPMS) name

[hgschmie]

This allows JPMS modules to depend on this component.

[hgschmie]

pretty ping?

[mikebell90]

We will be unable to look at this for a quarter or two I’m afraid . We are busy rebuilding our entire stack for spring boot 3 while maintaining the current one

…

On Fri, Sep 1, 2023 at 11:54 AM Henning Schmiedehausen < ***@***.***> wrote: pretty ping? — Reply to this email directly, view it on GitHub <#184 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF6QDIZHJPLQLIYWFN5T6DXYIVOHANCNFSM6AAAAAA3W2E6KM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hgschmie]

understood. In that case we will deprecate and might drop support for this component when we start moving more aggressively towards JPMS integration as we don't want to rely on a filename based automatic module.

[mikebell90]

whats your basic motivation for pushing JPMS? I ask out of curiosity because I've yet to be really convinced it's useful for apps as opposed to the sdk

[mikebell90]

Also what is "filename based automatic module"? I thought automatic modules simply were a manifest entry like what you provided

[hgschmie]

JPMS is a fact of life for JDK post 8 and many of the application servers and framework start to support it. As Jdbi is a library that is used in many contexts, supporting JPMS is useful to them and does not harm anyone that is not using JPMS (the module descriptors are not used if the jars are on the classpath).

JPMS is still a long way out (see https://github.com/jdbi/jdbi/blob/master/JPMS-SUPPORT.md) but we will eventually arrive there and I don't want to be held back by dependencies that don't have at least the very minimum of JPMS support (see below). Java 9 shipped six years ago.

There are two types of JPMS modules: "automatic" and "defined":

• defined modules have a module-info descriptor that defines their module name, requires, exports etc. This is the full JPMS support that we are working towards
• automatic modules is everything else. Any automatic module only has a module name and defined behavior (see https://github.com/tfesenko/Java-Modules-JPMS-CheatSheet/blob/master/README.md#automatic-modules for the explanation of the behavior)

The interesting piece is how JPMS arrives at the module name for an automatic module: It checks the manifest to see whether there is an "Automatic-Module-Name" entry. If yes, then this becomes the name of the module.

If that key does not exist, then it falls back to the filename (!) of the jar and uses that as the module name. The problem with this is that this is prone to renaming the jars. Providing the name in the manifest makes the module immune to that.

So the very minimum support that any jar should offer to JPMS over the last six years is to pick out a module name and put it into a key in the jar manifest. This is what this PR does and it ensures that a project depends on it, its module name stays stable.

[mikebell90]

If you could rebase, I'll try to find time to test this. thanks

[hgschmie]

rebased