Dynamic class loading

[Per Bothner]

> What developer A now wants to do is compile, using gcj, his classes (or
> some of them, anyway - the CPU intensive ones) into native code, but
> automatically provide jni stubs so that as far as developer B is
> concerened, they're just normal native classes.

It is not going to work, because the output of the gcj compiler is
very dependent on the run-time environment.  Thus it will not be
portable if (say) B uses the jdk.  And if it isn't portable, what's
the point?

On the order hand, one could change gcj to generate code that
is portable to any jvm that supports jni.  But there is no point
in that either, since the resulting code will be *slower* than
using an interpreter (due to all the required jni calls).

	--Per Bothner
bothner@cygnus.com     http://www.cygnus.com/~bothner