No I mean that exactly. I don't know, I mean the point of modularizing something for me is I may want to use your module but I don't care about its internals. Or at most, I don't want the internals of your module to affect me.
So yeah, you can expect your 3rd party libraries to "keep up" with the latest and greatest, but that's kind of an unreasonable expectation with fast paced technology. What I want is to use your library, but not have it affect the same libraries it might be using internally but that I explicitly depend on. BTW, when people say "classpath hell" (or jar hell) this is one of the main scenarios they refer to. http://c2.com/cgi/wiki?ClasspathHell ---------- One big need for OsGi / JavaModuleSystem? (JSR 277) functionality is to fix the ClasspathHell problem: * My application uses libraries "B" and "C", both of which use library "D". * But "B" and "C" require different versions of "D". * There's no version of "D" I can put on the CLASSPATH that will satisfy both "B" and "C". * Thus, I'm in "ClasspathHell" -- there's no "standard Java way" to fix the problem. ------------ I assume that the whole "Application Context" in Jigsaw means that for webapps and apps running in an EJB container you can overcome this but no I meant it more in a regular application outside of any of these containers. Augusto On Jun 28, 11:21 pm, Jess Holle <je...@ptc.com> wrote: > Augusto 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. > > It is essential for /some/ applications. > > Personally I generally prefer to make all the parties involved work > /really/ hard at allowing for and arriving at a single version of any > given library (ideally the latest stable version) to be used at runtime > rather than allowing multiple versions within an application. Using > multiple library versions in one application is pretty much a worst case > scenario to me -- and is generally a strong indication that someone is > not keeping their software up-to-date (i.e. so that it can use the > latest stable versions of the libraries it depends on). If that someone > is a vendor or 3rd-party component then that's generally a sign to go > shopping for another one -- unless, of course, you're the one who has > been foolish enough to stay on an old version of that component instead > of moving to the new version, in which case it is time to upgrade. > > -- > Jess Holle > > P.S. If you mean multiple versions just for things like a web app > reload, that's a different matter entirely, of course. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
