[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Notes from discussion on module definitions and tools
From:       Mandy.Chung () Sun ! COM (Mandy Chung)
Date:       2009-10-19 18:48:00
Message-ID: 4ADCB460.30305 () sun ! com
[Download RAW message or body]

Alan,

Thanks for sending the summary.

As a side note, Jon fixed 6888367 (classfile library parses signature 
attributes incorrectly) in b75 that changes some com.sun.tools.classfile 
interface (e.g. InnerClassType is removed).  I'm going to fix the 
ClassAnalyzer tool to work with the latest classfile library.  For the 
time being, you can continue to run ClassAnalyzer with b74.

Mandy

Alan Bateman wrote:
> Mandy and I had a discussion last week on the tools and the other 
> changes that we need to do as we prepare for the build to generate 
> modules. Here's my notes from that discussion (Mandy, correct me if 
> I've got anything wrong).
>
> We agreed that the module definitions need to be simple and easy to 
> maintain.
>
> With the current tool, we can allocate classes to modules based by 
> matching on package/class names or we can specify roots and have the 
> tool attempt to compute the transitive closure (or do combinations 
> of). Following dependencies is very useful for analysis purposes but 
> is fragile in that it requires hard-to-maintain filters to prevent the 
> tool pulling in classes that we don't want. We therefore propose to 
> use simple matching in the definitions (with the possible exception of 
> boot or base modules that are defined by other means).
>
> One implication of simple module definitions is that we will need to 
> look at a number of areas in the repository and split the packages or 
> move classes to more appropriate places. To give one example, the http 
> protocol handler supports the spnego authentication scheme that could 
> move into a sub-package to make it easy to assign to the 
> "security-kerberos" module. We'll likely conscript others to help with 
> this work.
>
> On tooling, we decided to create several "simple" tools, each doing 
> one job well rather than building a Swiss Army knife. The tools that 
> we discussed are:
>
> 1. The class analyzer that we use for analysis, possibly including 
> generating class lists for boot/base modules.
>
> 2. A relatively simple tool to assign classes to modules defined by 
> patterns. The modules definitions can be in a single file and ordering 
> is only important where the patterns overlap. It should be relatively 
> quick to run in the build and will output the class lists, 
> dependencies, summary, and one file with the module dependencies.
>
> 3. A simple tool that compares module dependencies against a 
> "checked-in" file. The tool fails if there if there is a dependency 
> that isn't listed in the checked-in version. An open issue is optional 
> dependencies where finer-grain checking would be required to detect a 
> dependency that has changed into a "hard" dependency.
>
> That's it!
>
>


[prev in list] [next in list] [prev in thread] [next in thread]