Jigsaw/JDK requirements

[Jonathan Gibbons]

While Mercurial can handle mass renames, it does it in a clumsy way 
(doesn't it?)
as a combination of a delete and a new file.  Although it doesn't cost 
you in the
working directory, it will cost you in the .hg directory, won't it?

-- Jon

Mark Reinhold wrote:
>> 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
>