API for determining the hash of a module

[Ethan McCue]

It's not that I *don't* want to use version numbers, it's that in general
it doesn't account for these sorts of constraints. When I can use jmod
describe and see "oh it can only be used with a java.xml that has this
exact hash" but can't look in my bucket of java.xmls and say which ones
have that hash - that's annoying.

It becomes more annoying if you expect anyone outside the JDK to make use
of that capability. I can't even make a restriction like "if they are
tightly coupled modules, they must have the same version and come from the
same provider."

The reason I discounted version numbers _in general_ is because I thought
module descriptors didn't record them. Annoying that jmod describe won't
show that info to me, so problem for later.

Essentially, to justify this further:

jmods have special powers that "normal" libraries do not

* They have a special sanctioned placement for shared libraries. Libraries
in jars need to extract them at runtime
* They can only be used on the module path. Yes you need to link first, but
that the standard library is the only thing which can _actually_ get the
encapsulation benefits of the module path is annoying. The only notable
time an ecosystem player has very politely asked to please be put on the
module path (javafx) its summarily ignored by almost everyone because
making an uberjar is so easy in the prevalent build tools
* They have dedicated places for metadata. Man pages and the legal folder
are conceptually very similar to the information carried by javadoc
artifacts and maven license metadata. In the case of the legal folder, it's
hard to argue it's not a better (if less immediately introspectable)
system. So if you squint it almost looks like "thing you publish" already.

And so to answer the question: "what is missing from JMODs that we aren't
using them as artifacts anywhere" I'm just trying to do it with the world
as it is and seeing what issues I run into. This means questioning
assumptions like "repositories hold independently selectable versioned
artifacts" because JMODs add a harder constraint sometimes or "all
libraries tell you where to get their dependencies" because handling one
library that wants @adoptium/java.base vs @corretto/java.base would be
crazy + not representable in module infos regardless.

On Mon, Dec 16, 2024 at 10:40 PM Peter Firmstone <
peter.firmstone at zeus.net.au> wrote:

> 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/20241216/525b3a36/attachment.htm>