This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the GCJ project. See the GCJ home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> 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