I'm not sure. My impression from the jigsaw interview is that the modules are primarily a compile time thing. At runtime all of the stuff in the bootclasspath will still get loaded by a single classloader, but potentially faster and skipping the unnecessary classes.
- J On Jun 29, 2009, at 12:53 PM, Alexey Zinger wrote: > Right, but my question is, once the necessary refactoring is done, > will the JVM benefit from the same startup time boost just by > relying on current class loader implementations as it would by > loading those pieces via a module framework? > > Alexey > > > From: Joshua Marinacci <[email protected]> > To: [email protected] > Sent: Monday, June 29, 2009 3:23:01 PM > Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse > > modularity is part of that refactoring. > we define modules for each major component of the JRE. then we start > moving code around and cutting ties to fit this new spec. the > compiler can then enforce the modularity. of course, this takes > time and not everything will be done in the first rev of OpenJDK 7, > but it's a good start. And the good news is that the JRE will > continue to get faster and slimmer over time. > > - J > > On Jun 29, 2009, at 12:18 PM, Alexey Zinger wrote: > >> Wouldn't modularization of libraries involving XML, I/O, and >> security necessitate the kind of refactoring that would result in >> the same speedup in the current JVM? In theory, class loaders only >> load what's necessary already, no? >> >> Alexey >> >> >> From: Joshua Marinacci <[email protected]> >> To: [email protected] >> Sent: Monday, June 29, 2009 3:09:30 PM >> Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse >> >> >> On Jun 29, 2009, at 11:25 AM, Alexey Zinger wrote: >> >>> 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. >> >> >> It may be trivial for server side apps where an admin downloads and >> preps the server and the app is only started once ever few weeks., >> but it's a huge problem for the client side. Every extra jar adds >> to your download and to your startup time. Modularity lets us to >> things like only download a jar when it's actually needed, and only >> load up into memory the classes that are actually used. Ex: >> webstart loads the xml libs which load up java.io which load up the >> entire security framework. For a simple app this is way more >> classes than need to be loaded and can triple the startup time. >> Modularity will solve this problem, resulting in apps that both >> install and start up many times faster. >> >> - Josh >> >>> 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 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 <[email protected]> >>> To: The Java Posse <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> wrote: >>> > >>> > > Augusto wrote: >>> > > > On Jun 28, 6:38 pm, Steve <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
