2009/6/30 Alexey Zinger <inline_f...@yahoo.com> > I don't know if the jar duplication problem is that compelling overall. > Even several megabytes of duplicated jar's seems like a drop in the bucket > these days. >
of course the gotcha with Google-Collections is that it includes its own background thread to clear references, so having several copies of that lib means several duplicate threads - but I agree not everyone will mind that I also like the way I can check my deployment using module metadata - I used to spend far too long messing around finding out exactly what jars I needed on the classpath, while with the right metadata I can use tools to do that for me (and it should be possible to do the same thing with Jigsaw metadata too) Certainly it would take a lot for any serious product vendor to be willing > to relinquish control over the libraries they depend on and risk their > dependencies not getting installed properly on the client. For years, OO.o > was shipping with its own whole JRE just in case. I think it's only > recently that it's become smart enough to recognize when the client already > has Java installed. > > And if we don't mind duplicated jar's, then having your own modularization > supporting multiple versions of the same jar is trivial. I wrote > this<http://bsheet.cvs.sourceforge.net/viewvc/bsheet/code/src/zinger/bsheet/module/ModuleFactory.java?revision=1.10&view=markup>as > part of my own plug-in architecture for an app several years ago: > > 160 public Module loadModule(Properties modConfig) throws > ModuleLoadException > 161 { > 162 String enabled = modConfig.getProperty("mod.enabled"); > 163 if(enabled != null && "false".equalsIgnoreCase(enabled)) > 164 { > 165 return null; > 166 } > 167 URL[] cpURLs = this.getCPURLs(modConfig); > 168 Module module = this.loadModule(new > URLClassLoader(cpURLs, this.getClass().getClassLoader()), > modConfig.getProperty("mod.impl.class")); > 169 module.init(modConfig); > 170 return module; > 171 } > > > That's the crux of it and it allows each module/plug-in to initialize in > the context of its own class loader, which in turn allows me to stuff > different copies of the jar's possibly containing different versions of the > same class into different modules. No problem. > > Where duplicate jars count seems to be the two opposite ends of deployment > spectrum -- mobile applications and app servers. In the case of mobile > deployments, right now we have two options: Java ME, which is as good as > dead in terms of forward momentum, and Android, which solves the modularity > problem at the core of its service-oriented architecture. And as far as app > servers, I suspect it's not a big deal for admins to keep control of shared > apps and employ whatever modularization they deem necessary -- if JVM comes > with it, they won't see a huge win over using an external modularization > framework. > > Alexey > 2001 Honda CBR600F4i (CCS) > 1992 Kawasaki EX500 > http://azinger.blogspot.com > http://bsheet.sourceforge.net > http://wcollage.sourceforge.net > > > ------------------------------ > *From:* mcculls <mccu...@gmail.com> > *To:* The Java Posse <javaposse@googlegroups.com> > *Sent:* Monday, June 29, 2009 3:21:16 AM > *Subject:* [The Java Posse] Re: more jigsaw vs osgi vs javaposse > > > On Jun 29, 12:27 pm, Augusto <augusto.sellh...@gmail.com> wrote: > > 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. > > [disclaimer: I contribute to OSGi projects and I'm co-authoring a book > on OSGi] > > exactly, that's why libraries often use tools to embed/repackage > dependencies: > > http://maven.apache.org/plugins/maven-shade-plugin/ > http://code.google.com/p/jarjar/ > > for example Guice has CGLIB and Google-Collections as internal > dependencies, > but I wouldn't want to be forced to use the same version of these > libraries when > using Guice - similarly the Guice team probably doesn't want to be > bothered with > problems caused by someone putting a different version of CGLIB before > Guice > on the classpath (the JVM will pick the first matching class when > scanning the > classpath, so ordering makes a big difference when there's overlapping > content) > > so Guice repackages CGLIB and Google-Collections inside the jar - > unfortunately > this means anyone who already has those jars gets duplicate content > (~400k?) > > now imagine if everyone does the same - you could end up with ten > copies of the > Google-Collection classes, embedded inside various libraries - you can > already > see this happening in applications today, and it's caused by a lack of > modularity > > if there was a standard modularity system that supported multiple > versions then > the Guice team could distribute just their classes (plus the necessary > metadata) > safe in the knowledge that regardless of what jars were on the > 'module' path, the > right version would be wired to Guice > > that's one of the reasons why I find module systems compelling - now I > can totally > understand why you might need a special framework to modularize the > JVM, just > like the JVM has the "Unsafe" class for internal use - but I'm a > little bit wary about > using the same solution for applications, exactly because it might be > optimized > for the JVM (for example the "no multiple versions" requirement) > > still hoping that JSR 294 will help bring both sides together in some > way... oh well, > time will tell - I'd hate for people to be put off the general idea of > modularity (and to > some extent programming to interfaces) as imho it does lead to better > apps > > -- > Cheers, Stuart > > PS. many thanks to the JavaPosse for doing both of the interviews in > the first place > > > 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. > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
