Some questions about using the same library more than once at different versions, for both folks knowledgable at OSGi, and anybody who knows how this is going to work in JavaFX:
1) The serious issue with the same library at different versions in use by 2 separate modules is the lack of interoperability. Let's say, for arguments sake, that the collections API was versioned, and module A is using v1, while module B is using v2. If module A communicates with module B via some mechanism (such as e.g. bouncing through the 'Main' app, or via interfaces directly to each other), then this is just plain not going to work - A's "List" isn't B's "List" - and that's that. This is unacceptable for any library that is commonly used across module boundaries (such as the core java runtime libraries - so those folks thinking that the modularization of the JVM is going to allow sun to break backwards compatibility - sorry, not gonna happen, unless this problem is solved) - but it also seems to be a ridiculously hard problem to solve. The only thing I can come up with is a way for a library to ship with 'view wrappers' that act and feel just like a certain version, but really just wrap through to the 'canonical' installed _real_ class code. That way, the only objects that are actually passed around are of the canonical version, and any module that is not compatible with that version instead sees a wrapper. How such a wrapper would work, especially considering a change like e.g. changing the swing code to return immutable Point objects in response to e.g. getSize() - shows just how complicated that's going to get. Does OSGi offer anything to address such an issue? At least jigsaw lets you interop between modules if you declare them all as local dependencies (and, yes, they all are capable of working with the same version) - but that's not exactly a nice solution either. 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 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. On Jun 29, 1:53 am, Augusto <augusto.sellh...@gmail.com> wrote: > On Jun 28, 6:38 pm, Steve <stephen.a.lind...@gmail.com> wrote: > > > If an alternative modularity platform for app developers was more > > compelling than OSGi I certainly would jump ship, but it would need to > > at least provide what the OSGi core does now (proper component > > encapsulation, supporting multiple versions of the same 3rd party jar, > > runtime dynamism, etc.). > > Multiple versions of the same jar is one thing I described in my blog > post incorrectly. Well, I said that was a core problem solved by a > module system but in fact Jigsaw doesn't seem to support it. It is not > needed for modularizing the JDK, but it is essential for modularizing > applications. I'd like to know a bit more as to how those type of > conflicts would be resolved in Jigsaw. The information that I have now > is that there are 2 different versions of a module in the same > classpath that would be an error, and only multiple versions would be > supported in different "application contexts" (which was sort of > Mark's answer in the BOF), but I'm not clear what an "application > context" means here. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
