incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: API changes
Date Wed, 13 May 2009 14:04:17 GMT
On Wed, May 13, 2009 at 1:14 PM, Andrew Johnson
<andrew_johnson@uk.ibm.com>wrote:

> Stuart Monteith <stukato@stoo.me.uk> 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.
>

The basic need I have is to be able to access an element directly by
index.   I don't want all the semantics of a list -  I just want  size() and
get(index)  capabilities.


> > 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
> list.
>
Thats true - but is the same for iterators.   What the list gives you is an
idea on quantity and the ability access an object directly.


> 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().
>

yep agree I dont want a modifiable list!

>
> 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))
> l.toArray();
> Collections.shuffle(l);
>
> 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:
> http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html
> 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
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>

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