But, Steve, I just named a rather obvious use case where every module states their own dependencies, and yet interop is absolutely required:
The java core libraries! Unless we decide to all talk in primitives and Strings to each other, it would all considered be a much nicer programming environment if there was a solution to this issue. Somehow. As I mentioned, it seems almost impossible to solve. However, most of the time when I talk to modularization fans (be it OSGi, or jigsaw, or agnostic), people forget this is a problem. Usually someone ends up asserting that a good module system allows libraries to break backwards compatibility. I can't remember the number of times I've rained on that particular parade. I'm flabbergasted nobody cares about this. While a hard problem to solve, I think it *IS* solvable. And, as to the 'local dependencies' thing - you'll have to go back to the jigsaw podcast. What I remember quite clearly is the following gist: (paraphrased from Mark and alex): "Unlike OSGi, jigsaw does _not_ consider split packages a big problem. We support local dependencies, which bundles everything up into one classloader, so you can split code that is tightly bound into multiple modules". The way they phrased it, it sounded to me like that was a choice: I want local dependencies, which allows interop but does not allow multiple versions, or I don't want local dependencies, in which case no interop, but multiple versions. I might be reading too much into how things were said. Does anyone have Mark and/or Alex's ear? I'm sure they know. On Jun 30, 1:06 pm, Steve <stephen.a.lind...@gmail.com> wrote: > > That's not really the point of the "multiple version" question. You're > unlikely to write an app that explicitly depends on two different > versions of the same library, as you point out using two versions of > the same class in a single module is not going to work (it doesn't > really make sense). You are, however, eventually going to write an app > where you end up with incompatible *transitive* dependencies (ie. > classpath hell). It's this sort of situation that OSGi can help you > with. > > > > > 2) Where is it written that jigsaw will not support runtime > > separation? I've heard time and time again that jigsaw offers a way to > > ESCAPE doing that (by way of the local dependencies mechanism), which > > Can you elaborate on this a bit? > > > suggests that by default jigsaw will use classloader-based tricks, or > > repackaging, to let you do runtime separation. However, this > > discussion seems focussed on the idea that jigsaw can't do this. Where > > is this written? I know, I know - jigsaw lacks specs, and we all (even > > the 'jigsaw fanboys') are very annoyed at that, but there's > > nevertheless quite a bit of info out there. If this information is NOT > > out there, I think we're jumping the gun. > > It should be a pretty simple question to answer, either it does or it > doesn't. Someone must know :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
