gback at cs.utah.edu
Mon Feb 7 13:42:11 PST 2000
> Derek L Davies <ddavies at world.std.com> writes:
> > Patrick Tullmann <tullmann at cs.utah.edu> writes:
> > > Its always easier to wrap a flexible interface an present it as a less
> > > flexible one, so I suggest going with the 'this' pointer approach. If
> > > it turns out that all the JVMDI code in the world is written to the
> > > singleton, no-this-pointer approach it should be pretty easy to wrap.
> > > Going the other way is much harder, I think.
> > I think I agree with Patrick. And I've pretty much written it already
> > using the 'this' approach. I need to resolve a few issues in my
> > implementation and then I'll give up the code. At this point it's
> > only a skeleton interface, no real functionality. I started with the
> > non-this approach but then changed to the this approach, so it's fairly
> > easy to go either way...
> Does this mean you will be wrapping your double pointer interface to
> follow the spec?
> As an aside, in C++ native methods still take a JNIEnv *, rather than
> a JNIEnv as a function argument, and still pass in a double pointer to
> JNI calls as argument 0. I don't understand why everyone keeps
> calling the JNIEnv** "this".
Jason, you have to explain that some more.
What's a double pointer? Why shouldn't they take a JNIEnv*?
How does this invalidate the view that passing the JNIEnv* pointer is
akin to passing a 'this' pointer?
Whether or not the 'this' pointer (in the figurative sense) is
implementationally identical to the 'this' pointer in the C++ sense
is implementation-dependent. As we know, it's usually not the case,
except for Microsoft's C++ compiler. Therefore, JNIEnv cannot generally
be implemented as a C++ class with virtual methods with compilers such
I agree with Jason that you have to stick to whatever Sun says, or else
don't use JVMDI. The only reason to use it would be interoperability.
Else design your interfaces.
More information about the kaffe