Properties

[Per Bothner]

Jeff Sturm <jsturm@sigma6.com> writes:

> Sounds good... any idea how we could map a class to a .so?  Add them to
> CLASSPATH maybe?

That has been my proposal all along.

The model we should go for is that you should be able to compile a
.zip/.jar archive to a .so archive, put it in your CLASSPATH,
and have things work more or less the same.

We need a model that can handle different kinds of .so:
(1) Ones specified at link time to gcj.
(2) One list in the CLASSPATH.  (Note that CLASSPATH should be
used by Class.forName even if the application was linked as a
standalone executable.)
(3) Other .so files, loaded by System.loadLibrary.

A CLASSPATH specifies an ordered list of ClassPathEntry.
ClassPathEntry is an abstract class containing:
        abstract public Class load(String classname);
The load method returns a loaded class, or nil if the
ClassPathEntry does not find a match.

The existing gnu.gcj.util.path.PathEntry is too specific
to loading bytecode classes; it should be a sub-class of
my proposed ClassPathEntry.

Class.forName just walks down the list of ClassPathEntry,
calling load until it finds a match.  If there is no match,
ClassNotFoundException is thrown.

Loading a shared library creates the ClassPathEntry, but
it should *not* load any of the classes in it.  This
is similar to the current implementation, where all .init
does is _Jv_RegisterClass.  We need to change that so that
.init just registers the class in the *current*
ClassPathEntry.  Better: have the linker create a ClassPathEntry
for each "object" (shared library or main program), so we have
a static name->class mapping.

The .init code for a .so will construct an instance of
CompiledClassPathEntry. This provides the mapping from
the names to the address of Class objects.

For the two sources of shared libraries, we may need different
rules:
(1) For shared libraries explicitly specified by CLASSPATH, 
we create corresponding CompiledClassPathEntry in the proper
place in the internal list.
(2) For shared libraries loaded by the initial dl loader before
main starts, there is the question where to put them in the list.
The most logical idea might be to put them at the tail end of
the list, after anything on the CLASSPATH list.  However,
performance and security reasons might suggest otherwise:
First search the CompiledClassPathEntry's for the "builtin"
shared libraries, then search CLASSPATH.  In fact, don't even
look at the CLASSPATH until we see a class that is not in any of
the "builtin" shared libraries.  (However, there could be an option
to search the builtin shared libraries last.)

Note in this model gij is just a regular application.
In fact, there is no reason it cannot be written in Java using
standard reflection features (though there is no particular
reason it should be).
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://www.bothner.com/~per/