Weldon Washburn wrote:
Archie,
I like your idea of zero mods to JCHEVM. I will attempt to localize
all mods to Classlibrary's Kernel Classes. Maybe this set of modified
Kernel Classes could be used by any VM that runs GNU Classpath.
I assume you're talking about making a "glue layer" that the standard
Harmony Classlibrary can work with?
I
will try some experiments with java class name space to see if we can
create wrappers that satisfy all the stakeholders.
TO me, the ideal is to have a very clear demarcation of what is the
Harmony Classlibrary VM interface.
So I'd see
Harmony VM Interface
--------------------------
Harmony/Classpath Adapter
--------------------------
JCHEVM
Is this what you mean?
geir
- Weldon
On 2/10/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
Because the wrapper is adding a layer of identically named methods and
thus potentially really confusing the name space, I renamed
java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray().
All the enties in _jc_ilib_table[ ] would also be "decorated" with
"wrapper".
Is that really necessary? It seems to me that the existing JCHEVM
native API can remain intact.
There are great advantages in being able to run JCHEVM with both
Classlib and Classpath at the same time for debugging purposes
(not to mention Classlib on J9). The more combinations you can
try, the easier it is to hone in on a bug's source. So I'd strongly
prefer that the Java/VM API remain the same as much as possible.
Certainly this can be done with the right "overlay" classes.
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
--
Weldon Washburn
Intel Middleware Products Division
