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 07:48:28 GMT
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