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 <jos...@gmail.com>
> To: javaposse@googlegroups.com
> 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 <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.
>>
>>
>>
>>
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
