Questions on the module-file format

[Mark Reinhold]

> Date: Thu, 04 Feb 2010 11:12:39 -0500
> From: karen.kinnear at sun.com

> I'm trying to figure out how we can speed up the initial download/
> application start time.
> 
> Is it possible to have more than one classes section? If for instance
> we wanted to be able to download a subset of classes and start module loading
> those before the download has finished for the rest of the classes?
> 
> I realize that there is a goal of "atomic updates" to the library, so
> I'm trying to figure out a way to do the incremental additions
> while keeping the repository consistent.
> 
> Given that individual modules will be added  to the library incrementally,
> there might be a mechanism that allows for "lazy addition" which holds
> the partially resolved dependency information, which perhaps can be
> lazily resolved in parallel with module loading.

There might be such a mechanism, but I bet it'd be pretty complicated,
especially in light of the need to keep module libraries consistent.

Rather than streamify the process of installing single large modules,
I think it's better to move the problem up a level.  An application that
needs to start quickly on first download can be structured as an initial
small "bootstrap" module with optional dependences upon the remaining
modules.  The bootstrap module is downloaded first and then installed and
invoked in parallel with the download, and eventual install, of the
remaining modules.  Code in the bootstrap module can use a simple API to
determine whether a specific remaining module has been installed yet.

To make this work we'll have to enhance the module-class-loader code to
allow live contexts to be augmented as more modules are installed.  That
will require doing version resolution and context construction for the
entire application at the time the bootstrap module is installed, before
everything else is downloaded.  Those calculations only need the
module-info files of the remaining modules, not their complete content,
and the module-info files will in most cases already be cached locally,
so that's not a problem.

One might object that it's awkward to have to structure an application in
this way, but a developer who wants this kind of behavior would have to
do something special with the streamed-large-module approach anyway, if
only to order the classes so that those needed first are placed earlier
in the module file.  Why not just make that explicit by putting those
classes in a special module?

- Mark