>>>>> "Tim" == Tim Ellison <[EMAIL PROTECTED]> writes:
Tim> I read the description of CNI here: Tim> http://gcc.gnu.org/onlinedocs/gcj/index.html Tim> Is there some description of how this looks from the Java side? Are the Tim> natives declared as CNI natives somehow, or does the VM go through the Tim> regular JNI dispatch (building a JNIEnv, function name mangling etc) to Tim> call the CNI method. Once in the native code I see how the unified Tim> object model works. The java side is plain old java, with the 'native' modifier for a native method. The choice of CNI or JNI is made at compile time. The default is CNI, you pass gcj the '-fjni' flag when generating object code to request JNI. -fjni causes gcj to emit special JNI-calling stubs -- the calling convention everywhere is CNI-ish, these stubs do the required translation (and call into libgcj to do the runtime linking required by JNI). The libgcj interpreter can only use JNI. So, there is no need to solve the "what does 'native' mean at runtime?" problem. Tim> How does the existence of this calling convention affect the choice of Tim> kernel types? I agree there will be different characteristics for Tim> kernel types written in JNI, CNI or Java, but since we agree that the Tim> replacement is at a Java class level then I don't yet see how this is so Tim> relevant. Yeah, CNI is largely orthogonal to, say, where the 'native' keyword appears in the Classpath sources. Generally speaking in libgcj we used to use native pretty liberally -- where ever it made life more convenient. The folks usually pushing a more strict separation into 'VM' classes are those with nontraditional VMs, where native has a different meaning, i.e. IKVM, or Jaos, or the oberon-based VM (I forgot the name of that one, sorry). Tom
