incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject API changes
Date Wed, 13 May 2009 10:41:54 GMT
Hello All,
    I'd like to start a discussion on changes to the API we should make 
before the Early Draft Review of the API.

One change to make would be to replace the Iterators with Lists. Steve 
has expressed a strong desire to do so as it will enable more useful 
ways to access the API.
Connected with this is the exception handling. Just now we return 
CorruptData objects, but these don't work when the Lists are strongly 
typed using generics.
Carmine has suggested always returning objects of the appropriate type, 
but instead have dummy objects of the appropriate type also implement 
the CorruptData interface.

As I see it it would look like so:

interface JavaHeap {
    List<JavaObject> getObjects();
}

Then we'd ordinarily return at least an object like so:

class JavaObjectImpl implements JavaObject {
}

and in error cases:

class JavaObjectCorruptImpl implements JavaObject, CorruptData {
    public ImagePointer getAddress() {
       return badAddress;
    }

    public String toString() {
       return badMessage;
    }

    public boolean isArray() {
       throw new RuntimeException("This object is corrupt.");
    }
}

so we would do something like the following:

JavaHeap heap = runtime.getHeap();

List<JavaObject> objects = heap.getObjects();

for (JavaObject obj : objects) {
    if (obj instanceof CorruptData) {
       System.err.println("Corrupt object: @ "+ 
((CorruptData)obj).getAddress()+":\""+obj+"\"");
       continue;
    }

    try{
        System.out.println("Instance: "+obj.getID()+" instanceof 
"+obj.getJavaClass().getName());
    }catch (CorruptDataException e){
       e.printStackTrace();
    }
}


Does this look sensible? More importantly, is this an improvement?

I don't like the idea of using a runtime exception within the corrupt 
object, I'd much prefer to return a CorruptDataException, with it 
perhaps returning itself.
Of course, this means adding CorruptDataException to every method, but 
at least that way we're not catching out our callers.
An even more friendly means of dealing with this problem is to use 
Steve's idea of having sensible defaults. Having said that, I don't like 
the idea of defaults messing up the statistics that may be being collected.

Looking forward to your thoughts and comments,
    Stuart


Mime
View raw message