Interfaces

[Godmar Back]

> 
> 
> 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
as g++.

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.

	- Godmar