On Tue, Mar 27, 2018 at 3:09 PM, Cédric Champeau <cedric.champ...@gmail.com> wrote:
> 2018-03-27 15:56 GMT+02:00 Gregg Wonderly <gregg...@cox.net>: > > > I think that Stephen is largely announcing that JigSaw presents more > > problems than it solves for the community. My list of issues, which I > have > > shared before, goes basically like this. > > > > 1. Modules should have versions which new tooling on community toolsets > > could use for managing details like maven is doing now, but without > > explicit version details available at runtime. There should be runtime > > version details available. Java’s dynamic binding mechanisms would > allow a > > lot more flexibility in how software was assembled at runtime, and that > > would be a good thing. > > > > I'm not sure what you mean by "modules should have versions". They do, > today, it's just not used, and I think it's a good thing. So I assume you > are talking about enforcing requirements on versions in the module info > file, in which case I strongly disagree. Disclaimer: I'm in the Gradle > team. We think it's the build tool system (or runtime system when runtime > plugins) do determine the right versions, given a set of constraints > provided by the producer (the library author) and the consumer. Any real > world application has version conflicts, and solving conflicts is *not* a > trivial business, so you clearly don't want the JVM to do it. What if a > library requires module X:1.0.1, but you discover a critical vulnerability > in X? Should you upgrade to 1.0.2?Where do you find this information? > Version ranges solve this problem. > Metadata is live, the only thing that the module should say, IMO, is > precisely what it does today: "I require this module", but then delegate to > the build tool the responsibility to find a version that works given all > requirements/constraints (environment, target JDK, vulnerabilities, ...). Whether or not JPMS enforces version constraints, the inability to even state a dependency upon a version of a module has created duplication.You have to state "require module" in module-info, and you have to repeat it with additional version information in the build descriptor (pom.xml, build.gradle, etc). If we could put a version requirement in module-info then the build tool could use that; this could have been achieved simply by permitting annotations on module-info 'require' statements. > I > think what the JDK does today is the right balance. In particular, > module-info is mostly focused on the runtime aspect, but there are clear > differences between what you need for compile, for runtime, or to compile > against a component. The constraints are not necessarily the same for all > those, so they shouldn't be mixed. > In what sense is module-info focused on the runtime aspect? It is enforced at both compile time and runtime, and yet it does not provide sufficient information for either the build tooling OR the runtime to assemble a consistent set of modules that work together.
