incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Johnson <>
Subject Re: API changes
Date Wed, 13 May 2009 12:14:05 GMT
Stuart Monteith <> wrote on 13/05/2009 11:41:54:
> 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.

I think that using Lists for JavaObjects from the heap is going to be 
unworkable if it implies having all the objects in the heap present in the 

Is the list modifiable? That would imply having a new copy each time, 
which could also be hard. You need to allow an implementation to 
prohibiting add, addAll, clear, remove, removeAll, retainAll, set. That 
way the list can be shared.
E.g. Collections.unmodifiableList().

You might be able to make the list for objects from the heap by wrapping 
the heap and getting an iterator when needed.

E.g. implement methods as follows
contains - get a new iterator, go along entire heap
containsAll - iterate twice?
get - iterate to get to required index

listIterator - could be tricky as the iterator can go backward which might 
be hard when traversing the heap.

You could easily have some expensive operations.

List l<JavaObject> = heap.getObjects();
if (l.subList(1,l.size).containsAll(l.subList(1,l.size-1))

If JavaObjects can't be done as Lists then it seem strange to allow others 
as Lists.

Lists imply ordering, which makes things predictable, but also allow 
duplicates. Would a Set be sufficient? This prohibits duplicates, and also 
doesn't have the tricky listIterator. The set could dynamically get its 
elements as needed from the heap. Is it worth enforcing a predictable 
ordering from the iterator?

The DTFJ/PHD reader included here:
has classes such as
class PHDCorruptJavaObject implements JavaObject, CorruptData
and PHDJavaHeap
        public Iterator<JavaObject> getObjects()

so the idea of using generics does work.

Andrew Johnson

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

View raw message