Files jvmti.h and jni.h in DRLVM are designed in a different manner than in classlib or in traditional JDKs. Each file is divided into two parts, jvmti_types.h/jvmti.h and jni_types.h/jni.h. Files jni_types.h and jvmti_types.h declare INI and JVMTI types, which are used internally in DRLVM code. Files jni.h and jvmti.h are for external usage.
If we are going to have one copy of jni.h and jvmti.h, they probably should be taken from DRLVM code, not from classlib code, because of this special design. Thanks. Ivan On 12/1/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ivan Popov wrote: > Header file jvmti.h (as well as deprecated jvmpi.h) from classlib does > not support C++ sources, only plain C ones. This is why JDWP agent > code, wtitten in C++, cannot use jvmti.h from classlib. > > DRLVM copies of jni.h and jvmti.h correctly support both C and C++ > sources, so we could use them and get rid of classlib ones. Its trivial to add the C++ support, so it doesn't matter which ones are retained -- I agree a single copy of these include files is fine. I can't think of an easy way off the top of my head to check for equivalence between them ... any better idea than tediously comparing? Obviously we need a copy of them available to compile the classlib native code, so any objections to keeping them there and DRLVM picking them up from the HDK? Other ideas? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
