- I avoid VMFoo instances (i.e, shadow objects). It seems to me that storing VM specific info in a shadow object serves no (runtime) purpose: if it can be represented in Java, store it in the original object, if it can't store it in a native C structure or whatever.
But just because it can be doesn't mean it will be. Having VMFoo classes allows the VM to choose whether to implement in Java or natively. If you end up using native then sure you have one extra level of indirection. But when you don't use native then a native method forces an extra level of indirection to "un-natify" it. We have very few native methods in OVM, at the "application" level.
This doesn't apply to JC (albeit a special case) because "JCNI" native methods and normal Java methods are exactly equivalent.. they're both compiled C code.
I prefer to see a VMFoo class with native methods, than a Foo class with native methods.
I'm not really arguing one way or the other, just pointing out that there is an inherent tension between goals. Obviously the VMFoo split is better for readability and ease of understanding, which counts for a lot.
-Archie
__________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
