Re: patches to re-direct _Jv_RegisterClass

[Per Bothner <per at bothner dot com>]

Tom Tromey <tromey@redhat.com> writes:

> But in this case we're loading classes based on something like
> `Class.forName("foo")'.  There is no compile time lookup for the
> caller.  There are no external references either.  For instance, we
> would use this mechanism when loading the AWT peers.

True.  Likewise for interpreted bytecode.  In both cases you need
search for a class at run-time.  As a general rule, that should be
done using the Classpath, so the question is how we organize the
default or builtin classpath.  We need to find a mechanism that is
both efficient and makes it easy to add new packages to the default
classpath.  The problem with using packing hierarchies to partition
.so files is that is only to a slight extent how people want to
install things.  I.e. if I have soem random Java application or
library I want to make it easy to compile and install it.

A simple solution is to have an directory file, which maps each
classname to .jar and/or sos providing it.  So whenever you install or
remove a library, you re-run the script.

> In this sort of case you'd probably just link against the .so using
> `-l'.

However, I don't want the Java depeloper to have to explicitly
add the -l - I want the software to do this automatically.
Expecting the programmer to keep track of which library
exports which classes is ridiculous.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/