---- Timothy Wall <twal...@dev.java.net> wrote:

Okay...,

I now have lots of code that looks like public class Image { private Pointer jnaPointer; public Pointer getPointer() { return jnaPointer; } protected void finalize() throws Throwable { Media.INSTANCE.destroyImageHandle(getPointer()); } ... // Methods actually relevant to an Image }

So, maybe JNA should provide this base class: public class WrappedPointer { private Pointer jnaPointer; public Pointer getPointer() { return jnaPointer; } public void setPointer(Pointer p) { jnaPointer = p; } }

and then I would have instead written public class Image extends WrapperPointer { protected void finalize() throws Throwable { Media.INSTANCE.destroyImageHandle(this); } ... // Methods actually relevant to an Image }

? (I haven't thought too hard about the public/private/protected decls on the above.) If JNA provides methods which expect WrapperPointers (in addition to
the ones that expect Pointers, I guess), does that help, or does it just make JNA more baroque? Thinking about it some (the initial version of this email got tossed
by the spaminator), I think this works. Everywhere JNA would take a Pointer, it
also takes a WrappedPointer. Most users will just extend WrappedPointer (rather
than perhaps wondering how to subclass Pointer, as I did). They don't have to
extend WrapperPointer; they could roll their own version of it (just as I was
obligated to do). The only difference when using this proposed WrappedPointer
is that the getPointer() call would happen inside JNA instead of in the user's
code, and the user gets type safety because he can claim that methods in the
Interface each expect certain subclasses of WrappedPointer.

So, it looks like a win. Well, to me.