Why not get rid of versions?

[forax at univ-mlv.fr]

Hi Paul, 

----- Mail original -----

> De: "Paul Benedict" <pbenedict at apache.org>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "ML OpenJDK Jigsaw Developers" <jigsaw-dev at openjdk.java.net>
> Envoyé: Jeudi 24 Mars 2016 20:05:23
> Objet: Re: Why not get rid of versions?

> 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?

You are asking how to encode version of dependencies (see [1]), I'm taking about not having a specific format for the module version, which is not really the same issue. 
If you use a build tool like maven, the resolution of the dependencies is done before running jigsaw so because the resolution is done offline, we already have a way to encode version of dependencies in the POM so we don't have to invent a new format for that. 
Maven will consume the POMs, find all the artifacts, download the web and show all the modules to jigsaw by setting the modulepath correctly. 

> 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.

This is part where we can not do exactly the same thing at compile time and at runtime, because doing the module resolution like maven does at runtime will make the application startup so slow that nobody will use it. 
We already try to do that in an early prototype, it's not a good idea. 
So like javac does more work than the VM, by example generics are simplified to be fast at runtime with the drawback that there are not truly reified, the works done by jigsaw at runtime can not be exactly the same as the work done at compile-time. 
jigsaw only validates that the dependencies are all presents at startup time and enforce the enhanced security declared in the module-info. 

> 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.

Currently, the only way to create a Layer is by using the API at runtime (it may change but that's another story), so a tool like OSGi (or JBoss Module or JavaEE module) will create a Layer using this API and knows how to interpret the version of a module because it's the OSGi code that will control the layer and will add the module into the layer. 

> 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.

see my answers above 

> Cheers,
> Paul

regards, 
Rémi 

[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionedDependences 

> 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?
> > 
> 
> > > >
> > 
>