incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject Replacing ImagePointer references in the Java Runtime API
Date Fri, 08 Jan 2010 10:22:08 GMT
I'm making made some good inroads into updating the API to match what we
discussed last year in decoupling the Image API from the JavaRuntime API,
A problem I've hit is that we can't use just a long to represent a
JavaObject id instead of an ImagePointer (which was one of the suggestions)

Currently the API for JavaObject lets you get an ImagePointer back to
represent its "id".    The JavaRuntime class allows you to provide an
ImagePointer and get back a JavaObject.   The original
idea was that we replaced these mechanisms with one where you could get a
long as an JavaObject Id and could provide JavaRuntime with a long and get
back the corresponding JavaObject.

It turns out that there are other places where we use the ImagePointer as an
"id" and do the eqivilent round tripping.  I need to fix them too.   Forcing
a implementation to reconstitute some of these other entities from a single
number is heavy handed - there is other context required in some places and
would require  an implementation to maintain a single name space (or is that
number space) for all of its entities.

To remove those dependencies on ImagePointer and provide a sensible round
tripping mechanism it seems better to go with a handle mechanism instead.
I'm going to prototype that  implementation but I thought I should explain
why I'm doing it that way up front.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message