<div dir="ltr">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 <font face="monospace">jmod describe</font><font face="arial, sans-serif"> 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.<br><br>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." <br><br>The reason I discounted version numbers _in general_ is because I thought module descriptors didn't record them. Annoying that </font><font face="monospace">jmod describe</font><font face="arial, sans-serif"> won't show that info to me, so problem for later. <br><br>Essentially, to justify this further:<br><br>jmods have special powers that "normal" libraries do not<br><br>* They have a special sanctioned placement for shared libraries. Libraries in jars need to extract them at runtime<br>* 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<br>* 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.<br><br>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.</font></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Dec 16, 2024 at 10:40 PM Peter Firmstone <<a href="mailto:peter.firmstone@zeus.net.au">peter.firmstone@zeus.net.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>If you don't wish to use version numbers, why not generate a
SHA256 hash of each module instead?<br>
</p>
<pre cols="72">--
Regards,
Peter </pre>
<div>On 17/12/2024 1:34 pm, Ethan McCue
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>That might be useful, but it is not closer to what I am
looking for.<br>
<br>
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. <br>
<br>
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)<br>
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.<br>
<br>
> Just to say again that theses module hashes are for
tightly coupled<br>
modules, they aren't the same as hashes that might be
generated when<br>
uploading a module artifact to a repository. <br>
<br>
They are if someone uploads JMODs to the repository.<br>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Dec 16, 2024 at
2:26 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
16/12/2024 02:12, Ethan McCue wrote:<br>
> I am experimenting with making a package repository
where modules are <br>
> the artifacts (bundled as JMODs) and not jars. In this
context we lack <br>
> information about what version a particular module
requires or what <br>
> provider to get that module from. What I *can* do is
say "if you use <br>
> this java.base, you must use this java.xml" and so on,
but given a two <br>
> java.xml modules I can't say without those hashes which
one you are <br>
> allowed to use when constructing a "module set".<br>
><br>
> This is relevant also if someone uploads some of their
own modules <br>
> where the hashes don't line up.<br>
><br>
<br>
Just to say again that theses module hashes are for tightly
coupled <br>
modules, they aren't the same as hashes that might be
generated when <br>
uploading a module artifact to a repository. For example, a
build of <br>
some project might produce 3 modules, one of which uses a
qualified <br>
export to make its internal API accessible to other two
modules. That <br>
internal API might isn't a stable interface. The hash that
the jar or <br>
jmod tools can generate at packaging time is used to tie the
3 modules <br>
and prevent accidental mixing of modules from Monday's build
with the <br>
modules from Friday's build.<br>
<br>
One thing that may be useful to your experiment is the <br>
"requires_version" in the requires entries of the Module
attribute. This <br>
is where a compiler can record the version string of a
dependency. It <br>
might be closer to what you are looking for.<br>
<br>
-Alan<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote></div>