> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > This means we can remove all private_data fields from Class
>
> Do you really need a C state for Class? If so, then this means that
> it will be impossible to associate a static C state with an object
> given the current NSA API.
>
It's perfectly possibly to achieve both of our goals. See below.
> > Better not ... every *instance* of Class needs a native state
> > pointer so that it can point to the ClazzFile.
>
> If this is necessary, it seems better to introduce a getClazzFile()
> function in Japhar rather than to change the current NSA API.
>
There is a jclass_to_clazzfile() function, if that's what you're talking
about. But it still has to somehow do the mapping from jclass -> ClazzFile
*. Right now, the way the function does the association is an int field in
Class. Using an actual field is deficient for >64bit machines, and it
creates a dependency on a private field. It would be cleaner if
jclass_to_clazzfile() was free to use the Class native state pointer to
associate this data.
>From what I can tell, here are all the requirements we're trying to fulfill:
(1) allow association of static native data with a class.
(2) allow the VM to use Class's native state pointer internally.
(3) make sure the native state interface does not refer to anything
Japhar-specific.
Here are three options which fulfill all our requirements.
(1) Add NSA_GetStaticNativeState(env,jclass), and let Japhar internally
attach a native state pointer to the ClazzFile itself. This allows it to be
VM independent (uses jclass instead of ClazzFile*, as it did previously) and
it allows maximum flexibility in the VM implementation. If you do this, the
VM-independent version can just call NSA_GetNativeState(env,jclass) since
the system obviously isn't using it already. This is my favorite solution.
(2) Change the Documentation. Pull what Sun pulled when they canned static
finalizers. Say that, instead of associating it with the Class object, they
should create an Object and put it into a static field associated with the
object's class. Then they call GetNativeState off of that Object.
(3) Have Japhar add a *second* native state pointer to the jclass for Class
only. This allows us to sidestep requirement #2. I dislike this solution a
*lot*, but it allows you to leave everything the same for
Get/SetNativeState. Please at least consider changing the interface,
though: it will be a lot harder to change later on.
Bottom line, I'm willing to bet that every VM is going to need some kind of
mapping between an internal class structure and jclass to support
Reflection. If you're talking about supporting this as an interface that
works on multiple VMs, this exact same thing is going to come up, again and
again. I suggest we fix it in a way that allows VMs to use the Class native
state pointer.
--John Keiser
