API for determining the hash of a module

[Ethan McCue]

That might be useful, but it is not closer to what I am looking for.

I am treating it as a constraint that the repository be able to hold
java.base, java.xml,etc. That those modules are tightly coupled is
information I don't want to lose.

If I have @corretto/java.base and @adoptium/java.base I can have some
heuristics about what they can be used alongside (like, must be same
provider + same version)
but its metadata I would have to add in special for those cases and I would
still not be able to handle if say, someone published @spring/spring.core
v1.0.0 and @spring-boot/spring.whatever v2.3.4 and those have hashed
dependencies recorded.

> Just to say again that theses module hashes are for tightly coupled
modules, they aren't the same as hashes that might be generated when
uploading a module artifact to a repository.

They are if someone uploads JMODs to the repository.


On Mon, Dec 16, 2024 at 2:26 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 16/12/2024 02:12, Ethan McCue wrote:
> > I am experimenting with making a package repository where modules are
> > the artifacts (bundled as JMODs) and not jars. In this context we lack
> > information about what version a particular module requires or what
> > provider to get that module from. What I *can* do is say "if you use
> > this java.base, you must use this java.xml" and so on, but given a two
> > java.xml modules I can't say without those hashes which one you are
> > allowed to use when constructing a "module set".
> >
> > This is relevant also if someone uploads some of their own modules
> > where the hashes don't line up.
> >
>
> Just to say again that theses module hashes are for tightly coupled
> modules, they aren't the same as hashes that might be generated when
> uploading a module artifact to a repository.  For example, a build of
> some project might produce 3 modules, one of which uses a qualified
> export to make its internal API accessible to other two modules. That
> internal API might isn't a stable interface. The hash that the jar or
> jmod tools can generate at packaging time is used to tie the 3 modules
> and prevent accidental mixing of modules from Monday's build with the
> modules from Friday's build.
>
> One thing that may be useful to your experiment is the
> "requires_version" in the requires entries of the Module attribute. This
> is where a compiler can record the version string of a dependency. It
> might be closer to what you are looking for.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241216/3b746ce8/attachment.htm>