ModuleFileFormat.java patches

[Mark Reinhold]

> Date: Thu, 25 Feb 2010 17:34:39 -0800
> From: mandy.chung at sun.com

> Mark Reinhold wrote:
>> ...
>> 
>>   - Changed the shape of the output tree so that it matches what
>>     SimpleLibrary expects:
>> 
>>         $DST/info             // module-info.class
>>             /classes/...
>>             /resources/...
>>             /lib/...          // Native libraries
>>             /bin/...          // Native commands
>>             /etc/...          // Configuration files
> 
> When jmod installs a module with native libraries and other
> non-java files, where will those files be installed?  Will
> they be installed in the module library exactly in the above
> layout?

Yes.  Non-java files currently in $JAVA_HOME/lib will wind up in
per-module etc directories.  At least that's the long-term plan ...

> I'm thinking about installing a jdk module (e.g. sun.management).
> Classes and resources are installed in the system module library at
> jre/lib/modules/sun.management/7-ea/
> 
> Would lib, bin, etc other directories be installed under the same parent as
> classes & resources (i.e. the module content
> directory)?

Yes, they wind up in the module-content directory, as shown above.

>              Or instead there is a way to specify the root
> to install the non-java files?

No, there is no way to specify that.

>                                 I'm worrying about the RPATH
> and native libraries search path.

Good point -- I hadn't yet thought this through.

Looking at the build today, we set the runpath at link time to point to
$ORIGIN, $ORIGIN/../{jre/,}lib/jli (for libjli.so, which is in its own
directory for some unknown reason), and in some cases $ORIGIN/.. (in the
various flavors of libmawt.so, so that they can find other libraries).

Most of our non-base libraries link to libjava.so and libjvm.so, so we'll
need to set their runpaths so that those can be found, but that should be
straightforward: $ORIGIN/../../jdk.base/7-ea/lib, or some such.

The trickier cases are when one native library refers to another across
non-base module boundaries.  This is not common but it does happen; e.g.,
libsctp.so refers to libnet.so.  We'll need to do a similar $ORIGIN hack
in those cases.

Until the build itself is modularized we can use the chrpath command on
Linux to modify the runpaths of our shared libraries.  I don't know
offhand if there's a similar tool on Solaris, or what the story will be
on Windows.

There may be a better solution here, but this seems workable.  An easier
short-term solution, for platform modules at least, might be just to
install them in $JAVA_HOME/lib/$ARCH as they are today.

> For jdk modules, "lib" directory may contain files other than
> the native libraries.  For example, sun.management has
> libmanagement.so as well as other property files under lib.
> Just want to mention it and I guess the above is just an example and doesn't
> mean to restrict it to contain native libraries only.

A module's properties files, and other configuration-type files, belong
in the etc directory.  There will eventually be an API for reading them,
and we'll need to make lots of little changes to change code that does

    File lib = new File(new File(System.getProperty("java.home"), "lib"));
    InputStream in = new FileInputStream(new File(lib, "foo.properties"));

or the equivalent to use that API.  For now, however, I suggest we just
leave all such files exactly where they are, in the base image under
$JAVA_HOME/lib.

- Mark