native cmds and libs in the module library

[Alan Bateman]

On 20/01/2012 17:56, Chris Hegarty wrote:
> Thanks Mandy,
>
> You are correct. I was storing absolute paths.
>
> Updated webrev:
>   http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.04/webrev/
>
>  - Paths to 'jmod create -L lib -natlib <dir> ...' are resolved
>    relative to the current working dir, as you would expect.
>  - natlib, natcmd, config, paths are stored relative to the module
>    library root, in the libraries metadata.
>  - The per module 'files' contains paths relative to the modules
>    install directory.
>
>  - I made most of the specific code suggestions you said, with the
>    exception that natlibs, natcmds, and configs can still be null
>    in SimpleLibrary. I use this to differentiate between a passed
>    path and a per module path.
>
> -Chris.
I think this quite good.

Can you briefly summarize how one would use this on Windows? I assume it 
requires specifying the --natcmd and --natlib to be the same directory.

In the simple library layout I added a flags word some time ago and it 
has many spare bits. Rather than storing 0 or 1 before each path then an 
alternative would be to use some of the spare bits.

A minor nit but the code style with if-then-else is a bit inconsistent. 
SimpleLibrary.storePath, SimpleLibrary.resolveAndEnsurePath, 
Librarian.Create.go are just a couple of examples that jump out (there 
are many more).

A general comment is that we'll need to go over this again once we get 
to clean-up the implementation, improve performance, make library 
operations atomic, etc. I mention this because what we have now is a bit 
inefficient and there's also quite a bit of hopping between new and old 
APIs. It will need a major clean-up at some point.

On the tests then I think an important test to include is a test that 
attempts to install a library or binary outside of the bin and lib 
trees. I think the validation code that you've added will catch this but 
I think a test is important.

-Alan.