2009/7/1 Reinier Zwitserloot <reini...@gmail.com> > > 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. >
to be fair I do know people who care about this, and they are trying to solve it for example the OSGi spec has a lot of detail (and theory) about class spaces and consistency - release 4 introduced so-called "uses" constraints basically to make sure both sides use compatible types when using a particular API: http://underlap.blogspot.com/2007/10/osgi-type-safety-and-uses-directive.html ( solving these sort of constraints is suspected to be an NP-complete problem ) but in the end you do have to agree on some point of interop - for OSGi that's often an interface because then you can have multiple implementations loaded but all sharing the same interface - usually via the lightweight service registry now depending on what happens to the interface over time changes how you can share it - if a bundle calls an implementation using interface A then it can also use later versions of that interface A' which have additional methods ( ignoring semantic issues of course! ) however, if you removed or refactored methods in an even later version A'' then the client wouldn't be able to use it because of the missing method(s). on the other hand, a bundle providing an implementation of interface A would not be able to use A' because it doesn't have an implementation of the added method, but conversely it could use versions of A which had methods removed ( again ignoring semantic issues ) so how do we decide which bundles get which versions of A to maximise interop? well at the moment in OSGi this is mainly done by specifying version ranges on your import packages (in the manifest) to declare what versions you can safely use - unfortunately getting these ranges right is hard, but there are tools that can help, like the API tooling in Eclipse 3.5 actually this exact topic came up at the OSGi BoF during Jazoon and there was a lot of discussion and suggested solutions, including using extra dimensions to define different aspects of compatibility rather than the linear version string we all use today (because this doesn't actually tell you much about compatibility) so this is definitely not solved yet, but I do agree that it is solvable also I should mention that OSGi also allows you to have split packages, though it is discouraged, by using Require-Bundle (ie. module level dependency rather than package level dependency) you can also have local dependencies inside your bundle (ie. same classloader) 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. > unfortunately reading the latest on jigsaw is still on my (long) todo list :( but I would also like to know if this is a developer choice or a limitation > 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 :) > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
