Jigsaw/JDK requirements

[Mark Reinhold]

> Date: Wed, 11 Feb 2009 08:41:46 -0800
> From: jonathan.gibbons at sun.com

> Are there any de-facto requirements coming from the desire to
> modularize JDK?  Specifically, is there are constraint to keep the
> shape of the source tree largely unchanged, or would we entertain the
> notion of reorganizing the source tree by module?

I don't think we should consider ourselves constrained to preserve the
current shape of the source tree.  In fact I think it's desirable and
appropriate to revise it significantly to reflect the coming, gradual
modularization of the product bits.  That way we can gain the benefits
of modularity not only when working on source code or delivering bits,
but also when working on the source tree itself.

I've been thinking that where today we have

    jdk/src/{share,solaris,windows}/classes/...
    jdk/src/{share,solaris,windows}/native/...

we will shortly have sibling subtrees

    jdk/src/{share,solaris,windows}/modules/...

where each module directory can have classes, native, and whatever
other subdirectories it requires.

Over time code will move from the first set of subtrees to the second.
We can consider the modularization effort complete when it's safe to
rm -rf the first set of subtrees.

>                                                    Would the SCM
> implications of that be way too onerous?

If they are, then we need a new scm.  Mercurial is, fortunately, quite
capable of handling mass renames.

> I ask, because it again comes up in the context of the shape of the
> classes tree, and the desire to have the classes directory structure be
> isomorphic to the source directory structure -- and Alex recently
> re-suggested encoding the module name (but not the version, this time)
> in the classes/ hierarchy.

This was the proposal to put module classes into classes/module-classes,
right?  That wouldn't be exactly isomorphic to what I outlined above, but
I'm not sure that it matters a great deal.

- Mark