API for determining the hash of a module

Peter Firmstone peter.firmstone at zeus.net.au
Tue Dec 17 03:39:47 UTC 2024


If you don't wish to use version numbers, why not generate a SHA256 hash 
of each module instead?

-- 
Regards,
  
Peter

On 17/12/2024 1:34 pm, Ethan McCue wrote:
> 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/20241217/a34ec3e5/attachment-0001.htm>


More information about the core-libs-dev mailing list