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 Mon, 06 Apr 2009 21:06:22 GMT
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