I tried (hard) to stay in problem-space in the first mail, but here are some opinions about solutions.
First, in case it wasn't obvious in the first mail, I very much agree that runtime is too late. I'm thinking it should be possible to do something in the linking phase. That would at least allow people to opt-in to better dependency resolution. Second, I also believe that trying to do automatic conflict resolution is too hard, and the best thing to do is to report errors. That means that there should probably be no distinction between problem variations 1 and 2; they're the same thing. Third, I think it should be perfectly OK for the linker to consider it an error if the same class were included twice with different bytecode. (Problem 3) I don't think it's a good enough solution to say that "it's the problem of module distributors alone". The reason is that I think it is impossible in theory and practice to say that "my module is compatible with dependency X from version Y and onwards". In theory because you never know what the developers of dependency X are going to do. Semantic versioning is just a guideline and people may break it inadvertently or intentionally. And in practice, because most library developers aren't going to be disciplined enough to find a good lower bound - I'm sure it would work well for modules in the JRE/JDK, but not in the wild. That means that neither lower nor upper bounds of compatible version ranges are going to be correctly specified in advance by module distributors. This in turn seems to mean that there should be a way to specify these ranges as problems appear and are discovered. I don't think this has to be a part of Jigsaw - one option could be some sort of transforming version of Artifactory where a company can add version compatibility information to artifacts as they are discovered. So we could specify that 'cassandra-core:2.0.5 works only with guava [15-18)' - either to a global compatibility repository or to some inhouse solution, or both. Not elegant, but I'm not sure that this is something that can be elegantly solved. Whether it's good or not, that particular approach would probably translate into requirements on the linker: the ability to detect and report conflicting version ranges (which already seems like a requirement), and possibly some considerations around separating module metadata (version ranges) from the module 'binary'. Maven, for instance, considers released artifact versions to be immutable and cacheable forever, but in this scenario the artifact metadata shouldn't be. A completely different solution could be something like what Ceylon does: http://ceylon-lang.org/documentation/current/spec/html_single/index.html#modulesystem. I understood from Mark that that would boil down to one classloader per module, which would lead to other problems. In summary, if it's not possible to actually solve this in Jigsaw, what I'd love to see would be a clear idea about what solutions might look like and ensuring that the module system has support for them. It's the sort of thing where abstraction boundaries might leak so it might be important to consider the format of module definitions, how the linker should behave, etc. / Petter On 5 February 2015 at 19:22, Martijn Verburg <martijnverb...@gmail.com> wrote: > On 5 February 2015 at 13:00, <mark.reinh...@oracle.com> wrote: > > > 2015/2/5 12:40 +0000, david.ll...@redhat.com: > > > I agree that working dependency resolution is a necessity for a working > > > software system. But, it is my opinion that run time is far too late > > > for this to occur (and I intend to carry this opinion into the JSR > > > working group). Ultimately it is up to the module distributor to > ensure > > > that their distribution contains a cohesive module set. While it is > > > possible to efficiently add certain types of validation checks at run > > > time, by this time it is far too late to do anything about a violation > > > other than just fail. > > > > Broadly speaking, I agree. At run time a module system should prevent > > broken situations such as conflicting module versions. It need not, > > however, attempt to solve them -- that's really hard, and it generally > > requires human intervention in order to identify the correct version. > > Simply failing in such scenarios (with a good error message, of course) > > is perfectly acceptable. > > > > I'll add my +1 to this - we also run across this situation on numerous > occasions and > for me I have strong preference to choose myself how to resolve the clash > as I have > the best knowledge of what versions I want in my app. > > At the moment we run careful Maven dependency scans at build time and other > interesting > classloader hacks at runtime to do this detection (when we operate with 3rd > libs at runtime > that we didn't provide). > > It would be awesome to have the module system tell me about these clashes > as opposed to > our runtime classloader hacks which are prone to all sorts of edge case > failures anyhow. > > Cheers, > Martijn > > > > > > > - Mark > > >
