Library delegation, the big JDK module, and modular launching

[Mark Reinhold]

I just flushed my Mercurial patch queues into the Jigsaw forest.
Herewith a summary of what's new.

Library delegation

  A module library can now have a parent library.  Each module in the
  parent that is not also present in the child appears to be in the
  child, recursively.  The Library find and read methods will consider
  the parent if something is not found in the child, but configuration
  operations only affect the child.

  In a related change I removed the Library.visitModules method, which
  wasn't much used and didn't make much sense in the presence of library
  delegation.  There's instead now a gatherModuleIds method which will
  return all module ids from a library as well as its parent, if any.

  When creating a library with the jmod command you can specify its
  parent with the -P option.  If you don't use -P then the parent will
  default to the JDK module.  You can use -N to specify a null parent.

  (Side note: I figured all along that we'd need this; I was trying to
   defer it to later but it greatly simplifies testing, so I did it now.)

The big JDK module

  At last!  The final phase of the build now creates the jdk at 7-ea module
  in build/lib/modules, by copying files from build/classes.  Classes in
  this module are loaded by a specialized Jigsaw loader which invokes the
  VM's bootstrap loader via the new j.l.ClassLoader.findBootClass method.

  During module configuration, if a module doesn't declare a dependence
  upon a "jdk" or "jdk.*" module then a dependence upon "jdk at 7-ea" is
  automagically added.  (Hmm, perhaps we could call this the "Miranda"
  module ...)  This is temporary: Ultimately the compiler should add such
  default dependences, and they should be upon the more abstract "java at 7"
  module, which the jdk module would provide, but this works for now.

  This changeset also includes some basic performance work, to cache
  ModuleId hash codes and to use identity rather than value equality in
  the Context and Configuration classes.

Modular launch sequence

  This was the fun one.  I've hacked the launcher (src/share/bin/java.c)
  and related logic in j.l.ClassLoader and elsewhere to be able to launch
  a root module by name, invoking the main method of the class declared
  in its module-info file.  To launch a module you just say:

    $ java [-L <module-library>] -m <module-name>

  When the JRE is started up this way the "system" class loader is just
  the Jigsaw loader for the named module, which -- due to the default
  library parent and dependence on the jdk at 7-ea module -- delegates to
  the Jigsaw boot loader to find classes formerly found in rt.jar.

  (I do have to admit that routing around the old sun.misc.Launcher class
   and the innate complexity of URLClassLoader and friends was a distinct
   pleasure.)

Of course I've also upgraded all the runtime code and tests to use Jon's
new module-path-aware javac (thanks!).

(Side note: I heavily used Mercurial patch queues for the first time
 while working on this set of changes.  Highly recommended!)

My next task will be to simplify the Resolver interface for Jon, and then
it'll be time to start <a href="knives-sharpening.ogg">slicing up</a> the
big JDK module.

Onward!

- Mark