Modules merging support in ClassAnalyzer

[Mark Reinhold]

> Date: Tue, 27 Oct 2009 22:26:44 -0700
> From: mandy.chung at sun.com

> I have implemented the modules merging support in ClassAnalyzer.  The syntax to
> specify the group module (i.e. enclosing module) for a module is to prepend the
> group name to the module name separated by ":" (i.e. <group name>:<module
> name>.  The group name is optional.  For example, "jdbc" is a group module
> containing jdbc-base and jdbc-enterprise whereas httpserver module itself is
> considered as a single group.  The group name and the module name have to be
> unique.
> 
> module = jdbc:jdbc-base
> include = java.sql.*
> 
> module = jdbc:jdbc-enterprise
> include = javax.sql.XA* javax.sql.rowset.**
> 
> module = httpserver
> include = com.sun.net.httpserver.** sun.net.httpserver.**
> 
> Classes in jdbc-base and jdbc-enterprise will be merged to form the classlist
> of the jdbc group module.  The class analyzer will generate <group>.summary and
> <group>.dependencies files.  It can generate <group>.classlist file but it
> currently doesn't.  We will use the fine-grained module classlist for the build
> and so <group>.classlist may not be needed.
> 
> It also generates groups.summary and groups.dot (like modules.summary and
> modules.dot) and they show the module dependencies in the group level (or the
> module itself if group is not specified).  e.g.
> 
> jdbc -> enterprise-base
> jdbc -> jaxp-parsers
> jdbc -> jndi
> jdbc -> logging
> httpserver -> logging
> httpserver -> security-jsse
> 
> Any comment/opinion on this syntax?

I think it would be cleaner, and simpler, not to introduce a two-level
naming scheme and a distinct concept of "group" module.  Instead just
have modules with a single flat namespace and the ability to include one
module into another.  The analyzer would only generate output files for
"top level" modules, i.e., those that are not included in any other
module.

This would allow the fine-grained modules we've been using for analysis
to be defined independently of the coarser-grained modules we'll use when
we actually modularize the build.  Ideally such definitions could be kept
in two separate files in order to allow easy experimentation.

In concrete terms:

  module jdbc-base
  include java.sql.*

  module jdbc-enterprise
  include javax.sql.XA* javax.sql.rowset.**

  module jdbc
  include jdbc-base jdbc-enterprise

This would generate just jdbc.{classlist,dependencies,summary}.

> Alan suggests to remove the "module" key and instead have the module name
> quoted in a square bracket like this:
> 
> [base]
> 
> [jdbc:jdbc-base]
> include = java.sql.*
> 
> I don't have any objection to this syntax change.  I can make the change along
> with the modules merging support.

If we're going to change the syntax then I'd like to see it evolve toward
something more like that of module-info.java files.  We'll gradually need
to add more module-info-like constructs (e.g., permits), and in the long
term I'd like the tool to be able to generate the module-info.java files
which we'll need in the build.

Something like this:

  module jdbc-base {
    include java.sql.*;
  }

  module jdbc-enterprise {
    include java.sql.XA*, javax.sql.rowset.**;
  }

  module jdbc {
    include jdbc-base, jdbc-enterprise;
  }

- Mark