native cmds and libs in the module library

[Mandy Chung]

On 1/6/2012 8:14 AM, Chris Hegarty wrote:
> Here is an updated webrev incorporating the feedback I received.
>
> http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.01/webrev/
>

This is a good start.  We can extend this approach for the
configuration files section as these files are intended
to be edited by the users; otherwise the users would require
to know the module library layout to find the config files.

The jdk modules in the current jigsaw prototype don't have
the "configs" section because it requires changes in the
JDK implementation to get the properties file at the new
location (possibly add a new API to obtain it) that hasn't
happened yet.  The properties files currently remains under
the $JAVA_HOME/lib directory or its subdirectory as in the
legacy image.  It also requires changes in the jdk build.
It would be good to add the support now to prepare the future
transition.

It makes sense to me to specify an alternative path for the
native cmds and config files when creating the module library
but I am not quite sure about the native libraries.  Native
libraries in a module are typically the implementation to support
its own module and not have a dependency on another.  There
are 7 jdk modules that have native libs but no native cmd nor
config files.  jdk.sctp is the only module whose native lib
(libsctp.so) has dependency on native libs on another module.
There are 6 jdk modules that have native libs and also either
native cmds or config files.  Attached is the matrix I have
from the jdk I built with module views prototype.

I am wondering what the common use cases are and whether
--natlib option should be a per-module base or per-library base?

For the per-library base as in your proposal, it's simpler and
consistent with other files (native cmds and config files) but
modules with native library but no dependency on other module's
native library can only support one single version unless the
native library uses shared library versioning.  Would it make
sense to support the --natlib option as per-module base
(i.e. jmod install option)?

> It would be nice to allow an override of files in the module libraries 
> natlibs or natcmds directories if a newer version of the same module 
> is installed. Currently this will fail due to a conflict on these 
> files. This shouldn't be difficult to add later. 

In addition, when we remove a module of a specific version, it
should restore natcmds/natlibs in the latest version of the same
module in the module library, if present.

As for my comments to the implementation, I agree with Alan
that the filename "oomfiles" is a bit strange and simply
naming it "files" seems good to me.  Some other comments:

ModuleFile.java
    L129: Rather than passing SimpleLibrary as a parameter
    to the Reader constructor, perhaps it's better to pass
    the paths to the readRest method to specify the destination
    to install section content for different section types.

    L450-454&  472-476: it might be good to combine the
    markNativeCodeExecutable and trackOutOfModuleContent methods
    as both are post-extract steps.

    L567-587: as Alan also pointed out, this might be worth
    having a method to return the path of a given section type.

SimpleLibrary.java
    L264: Files.ensureIsDirectory is the same utility method
    but is private.  Perhaps just use the existing one.
    L287, 302: looks like these lines can just call the
    ensureDirectory method.

Librarian.java
    L50-51: this can be replaced with Library.systemLibraryPath().

Mandy

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jdk-modules.txt
Url: http://mail.openjdk.java.net/pipermail/jigsaw-dev/attachments/20120109/3e4e8d86/jdk-modules.txt