Why not get rid of versions?

[Paul Benedict]

Remi, I would like to engage you more on this topic, especially on your
statement: "ease the interrop with module systems that does their
resolution at runtime"

Let's say I have a project that relies on Apache Commons Collections. My
project is dependent on version [2.0, 3.3) -- that's the physical version
string in my POM.

Now if the build tool is meant to bake the version into the class file,
there are two choices here: "[2.0, 3.3)" which is a version range OR the
actual version range resolved at build time. So the first question is going
to be which version should the class file receive? Part of the Module
Requirements is fidelity across build and runtime. If fidelity is to be
retained, there is an argument either way which version should go into the
class file. Allowing "[2.0, 3.3)" would give a module system much freedom,
but, on the other hand, what is selected at runtime may not be what was
built against.

The second question is how a layer/configuration is ever going to know *a
priori* (i.e., with prior knowledge) what the version strings mean? I think
the underlying assumption all this time is that the version, while opaque,
is going to be an exact match .... but we know tools like Maven (and I
believe OSGi, if Neil can opine) allow version ranges.

To me, these are two worlds colliding that shouldn't. As I said, the
versioning is important for the build but it should be completely
irrelevant at runtime in all cases. I want to make sure OpenJDK has
seriously vetted that requirement because using the Version for runtime
resolution, I think, is not going to pan out well. That requires knowing
what these syntaxes mean and, as we've seen from David's attempt with the
Version class, there is a whole host of schemes out there.

It's my opinion the Version should *not* ever be used for "resolution at
runtime" but only for build time. At runtime, it's informational only and
not an input to any functional requirement.

Cheers,
Paul

On Wed, Mar 23, 2016 at 10:06 PM, Paul Benedict <pbenedict at apache.org>
wrote:

> Okay, I see. They get baked into the class file by the build tool. Well,
> what if they weren't there at all? Every module system today already has
> external metadata and it is more descriptive than starting it from scratch
> in the JDK (see #StandardModuleAttributes). All I would ask if there could
> be given some thought about this, especially if it has a chance to reduce
> some complexity of the Module specification.
> On Mar 23, 2016 7:57 PM, "Remi Forax" <forax at univ-mlv.fr> wrote:
>
>> yes,
>> module versions are just metadata, as you said they are not needed by the
>> JDK,
>> but jigsaw also wants to ease the interrop with module systems that does
>> their resolution at runtime,
>> so IMO the JDK has to provide a way to query the version of a module at
>> runtime.
>>
>> Rémi
>>
>> ----- Mail original -----
>> > De: "Paul Benedict" <pbenedict at apache.org>
>> > À: "ML OpenJDK Jigsaw Developers" <jigsaw-dev at openjdk.java.net>
>> > Envoyé: Jeudi 24 Mars 2016 01:45:41
>> > Objet: Why not get rid of versions?
>> >
>> > Based on today's discussions, I've been thinking if there is any merit
>> in
>> > dumping the notion of Module Version altogether? I am beginning to think
>> > it's completely irrelevant to the Module System.
>> >
>> > Versions are important during builds and for interacting with artifact
>> > repositories, but once artifacts are resolved and installed into the
>> JDK as
>> > modules, versioning has no more utility. You don't even need Versions to
>> > link modules together. The only thing that is actually needed is the
>> Module
>> > Name.
>> >
>> > It looks like to me versions are metadata that belong outside the JDK
>> and
>> > classfile format. I think a whole host of problems go away when the
>> Version
>> > goes away. The JDK isn't an artifact manager so it doesn't need
>> versions.
>> >
>> > What do you think?
>> >
>>
>