From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernd Kreimeier To: Per Bothner Cc: java-discuss@sourceware.cygnus.com, classpath@gnu.org Subject: Re: Proposal for CNI/JNI problems Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14465.8056.983245.57682@ares.lokigames-lan.com> References: <14464.63457.898745.667839@ares.lokigames-lan.com> <14465.3924.684222.646003@ares.lokigames-lan.com> X-SW-Source: 2000-q1/msg00084.html Per Bothner writes: > of that with a direct field access in CNI. Following that chain > can be difficult when (e.g.) a jfieldID is cached. It may require > some global analysis (i.e. more than a single method). That's what I meant. So, it should be easier to do the reverse (expand CNI to JNI calls) but then ID caching and other optimizations would have to be added automatically as well? > > If a hypothetical G++ "emit-jni" option would generate JNI C > > G++ emits assembly code, not C. -femit-jni would emit binary > code *equivalent* to JNI C (i.e. *as if* compiled from JNI C), > but not actually C. I know that's the current proposal. Why is CNI-to-JNI C conversion out of the question? It would address some issues (like porting to non-G++ platforms, Hans Boehm's point (2), etc.). > Those are certainly important concerns. We may have to settle > for conditional compilation in tricky cases. OK IMO. Now, wouldn't CNI-to-JNI C ease identifying related problems? Is it significantly easier to map on assembly level? There'd be little point in a C level conversion if this inevitably led to "cfront-with-Java-structs" for mixed C++/CNI code. Is that the case? b.