A javalobby discussion thread involving these URL's

http://www.javalobby.org/forums/thread.jspa?messageID=92022890&#92021332
http://www.javalobby.org/forums/thread.jspa?messageID=92022890&#92021363
http://www.javalobby.org/forums/thread.jspa?messageID=92022890&#92021368
http://www.javalobby.org/forums/thread.jspa?messageID=92022890&#92021529
http://www.javalobby.org/forums/thread.jspa?messageID=92022890&#92022407
http://www.javalobby.org/forums/thread.jspa?messageID=92022890&#92022855

The concept is to address the large download by having a smallified JRE that
can still update itself to the full platform. The smallified JRE would not
match the full platform spec, but making the update of missing components would
make it easy to upgrade the smallified JRE to match the full platform spec feasible.
Further, this mechanism could be used for in-place updating of installed JRE/JDK's.

Let me make the observation that ... as we add features to the platform, we're
fighting a losing battle against the download size. By insisting that the platform
download contain the full platform we're fighting against ourselves and the incessant
desire for new features. By componentizing the platform we would get a more
fluidly updatable product, and by having a smaller initial download we'd get
a lesser acceptance barrier.

The implementation would have these features

- A SmallJava JRE that has a minimally useful set of capabilities. What this
means is TBD, but clearly networking is one of the base capabilities.

- The full platform would be divided into components (packages) that can be
easily downloaded and integrated to the JRE. One possibility is that means each
of the packages are individual .jar files that get put into something like
the jre/lib/ext directory.

- A "repository" configuration which defines a place from which the packages
get downloaded.

- A command like "java-get" which lets a user or administrator query the repository
for packages, retrieve packages, install packages, delete packages that have been
installed, etc.

- A change to the JRE so that attempts to use a class in a package that hasn't
been installed, results in an Error being thrown describing what package needs
to be installed along with the command line to run to do the install.

Usage could be relatively simple. The user downloads an application, runs it, and gets
a message saying "package X is missing from the JRE, please run 'java-get install X' to download it".

The user experience would be tricky to get right ...?

For implementation and usage hints we can look at the Debian packaging system, the
CPAN and PEAR repositories for Perl and PHP, etc.

Beyond handling the installation of missing components this offers a possibility for
updating components piecemeal. e.g. each component registers with its version number.
Then when we later fix a bug in the component, we'll bump the version number, and
the packaging system can check for updated version numbers on the installed components
and then take some action such as a) notify the admin, b) do nothing, c) automatically
download and install the thing.

Another possibility is cleaner handling of optional extensions. The current mechanism
for them is pretty gronky, whereas it could be a simple matter of the admin using
this packaging system to download/install the extension.

Third party extensions could work with this as well. The list of repositories could
be configurable so third parties can offer packages (e.g. jpackage.org).