incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carmine Cristallo <carminecrista...@gmail.com>
Subject Re: Kato API javadoc
Date Wed, 08 Apr 2009 10:09:20 GMT
What scares me is having to re-read whole threads of conversations of dozens
of emails just to find out what subjects have been touched that require a
decision.What I was thinking is that we could maybe create some form of work
item about each of these subjects and move the discussion there, or to keep
track of the items in some other structured way ... What do you think?

     Carmine

On Mon, Apr 6, 2009 at 10:06 PM, Steve Poole <spoole167@googlemail.com>wrote:

> On Mon, Apr 6, 2009 at 9:31 PM, Carmine Cristallo <
> carminecristallo@gmail.com> wrote:
>
> > Hi all!A number of potential work items are starting to emerge from this
> > thread. I'll try to enumerate them:
> >
> > 1. refactor the API to use generics. Basically, every method that now
> > returns an Iterator should have its signature modified. And while we're
> at
> > it... is Iterator<...> the right "thing" to return? Wouldn't a collection
> > (List<...>?) suit better?
> > 2. give a better implementation - as the one suggested by Nicholas - to
> > ImageThread#getRegister(). How about renaming it to "getRegisterMap()",
> > returning a RegisterMap interface?
> > 3. refactor the TCK to decouple the setup classes from the test classes,
> as
> > suggested by Stuart.
> >
> > Steve... should we start to open Jira work items for the above
> activities?
> >
> > How about we just start some discussion threads on this list first - and
> then create jira items to cover agreed changes to the API?
>
> >
> >     Carmine
> >
> > On Mon, Apr 6, 2009 at 8:24 PM, Nicholas Sterling <
> > Nicholas.Sterling@sun.com
> > > wrote:
> >
> > > It's very nice being able to look at this javadoc -- thanks!
> > >
> > > It might help to have a little introductory text in some of the key
> > classes
> > > giving some context, something along the lines of the DTFJ example on
> > your
> > > web site that opens a core dump and iterates through the threads.
> > >
> > > I wonder if ImageThread should return interface RegisterSet, of which
> > there
> > > would be various implementations for various CPU types, each containing
> a
> > > map from a Register enum to a RegisterValue.
> > >
> > > I hadn't realized until I started looking through this javadoc how much
> > > easier the use of generics makes it to understand an API.  For example,
> > > under JavaClassLoader I see methods getCachedClasses() and
> > > getDefinedClasses(), but I can't tell from their signatures whether
> they
> > > return the same type or not.  That info is in the method descriptions,
> > but
> > > it's a lot more work to flip back and forth between the Summary and the
> > > Detail.
> > >
> > > Nicholas
> > >
> > >
> > >
> > > Steve Poole wrote:
> > >
> > >> On Mon, Apr 6, 2009 at 6:51 AM, Nicholas Sterling <
> > >> Nicholas.Sterling@sun.com
> > >>
> > >>
> > >>> wrote:
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>> Great!  I've passed this on to the HotSpot folks for comment.
> > >>>
> > >>> I think I remember us talking about there being some provision for
> > >>> accessing the vendor-specific VM constructs that implement the heap,
> > >>> etc.,
> > >>> in addition to the Java objects in it.  Will that be done by, for
> > >>> example,
> > >>> casting a JavaVM to a HotSpotVM and using the latter's extra methods?
> > >>>
> > >>>
> > >>>
> > >>
> > >> That's the most obvious solution I think.
> > >>
> > >>
> > >>
> > >>> Also, I'm seeing methods that return Iterator with no type (e.g. in
> > >>> JavaMethod).  Is that just a temporary placeholder which will
> > ultimately
> > >>> get
> > >>> a type?
> > >>>
> > >>>
> > >>
> > >>
> > >> That's an interesting question.   The reason for there being no type
> > info
> > >> is
> > >> that the API was designed to compile and run on 1.4.2.
> > >> We need to decide if that still makes sense.   I know that 1.4 is out
> of
> > >> support by Sun and IBM.    What about Oracle?
> > >>
> > >>
> > >>
> > >>> Nicholas
> > >>>
> > >>>
> > >>>
> > >>> Steve Poole wrote:
> > >>>
> > >>>
> > >>>
> > >>>> Well at last ! -  we actually have the API javdoc available - 
it's
> > here
> > >>>>
> > >>>>
> >
> http://hudson.zones.apache.org/hudson/view/Kato/job/kato.api-head/javadoc/
> > >>>>
> > >>>> I'm certainly not going to hold this up as a the greatest javadoc
in
> > the
> > >>>> world but its a good place to start.  I do feel that we have
>  finally
> > >>>> arrived :-)
> > >>>>
> > >>>> The API has lots of "DTFJ"ness to it that needs to go but I'm really
> > >>>> interested in intitial reactions to the javadoc -  is the form
of
> the
> > >>>> API
> > >>>> what you expected?
> > >>>>
> > >>>>
> > >>>> Moving on - there is still code needed to make the API work (we
need
> > to
> > >>>> get
> > >>>> the hprof support working)   but  we can make progress in the
> interim.
> > >>>>  I
> > >>>> want to move quickly towards having a regular heat beat where we
are
> > >>>> moving
> > >>>> through the usecases that we have.  To do that we need to  get
 up
> to
> > >>>> speed
> > >>>> with the API shape as it stands today.    Stuart has published
some
> > info
> > >>>> on
> > >>>> the  API but its not really sufficent for educational needs :-)
> > >>>>
> > >>>> Is it worth holding a conference call so that we can walk through
> the
> > >>>> API
> > >>>> to
> > >>>> explain why its the shape it is or is everyone comfortable with
just
> > >>>> more
> > >>>> doc?
> > >>>>
> > >>>> Cheers
> > >>>>
> > >>>> Steve
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >
> >
>

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