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: Kato API javadoc
Date Wed, 08 Apr 2009 14:06:45 GMT
On Wed, Apr 8, 2009 at 11:09 AM, Carmine Cristallo <
carminecristallo@gmail.com> wrote:

> 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?
>

Ah - now I understand.  yes I agree it would be good to have a definitive
list of items for discussion - using jira to track an discussion item from
inception to final resolution would be great.  We should still keep the
topic discussion here though but in a separate thread.

>
>     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