Final version of First Early Draft Review document

[Steve Poole <sp...@googlemail.com>]

Hi all,   I've just posted the final version of the first EDR to the wiki
here http://cwiki.apache.org/KATO/jsr326specification.html      I'm going to
just check that I have everything in order process wise and then I'm going
to send that doc to the JCP as our first EDR.

If I've got all the JCP process stuff right then it will take a couple of
days for it to appear on the JCP website here
http://jcp.org/en/jsr/detail?id=326

In theory that is the point where the specification becomes public but since
we've always had an open approach that's not true for us.   I will be
expecting comments from the public to appear on this mailing list.

I'll point out again that the EDR is not complete - there are quite a few
places where we need to resolve questions and expand the descriptions.

Please take a look and comment  - or even provide some more words :-)

Cheers

Steve

Re: Final version of First Early Draft Review document

[Steve Poole <sp...@googlemail.com>]

On Thu, Sep 10, 2009 at 4:03 PM, Adam Pilkington <
pilkington.adam@googlemail.com> wrote:

> I'm currently reading through the EDR, so I'll post my comments ad-hoc
> as I progress.
>
> I'm looking at the CorruptData interface and wonder if the
> getAddress() method should be renamed so that there isn't a clash with
> other getAddress() methods. The reason for this is that if you wanted
> to use generics at some point, then when an iterator wants to return a
> corrupt object it would do so by returning one that additionally
> implemented the CorruptData interface. However this could lead to a
> clash e.g. ImageSymbol.getAddress() and CorruptData.getAddress() for
> an object which was representing a corrupt ImageSymbol, and care would
> need to be taken in order to ensure that you are working with the
> correct method.
>
> Given that CorruptData can be implemented by any object, would it be
> better to ensure that it uses unique method/field names to prevent
> confusion and increase code clarity ?
>

I don't really like the idea of  CorruptData having any methods other than
maybe something to help explain what type it corruption it is.

I've been thinking that the methods that exist which allow you to
potentially access the "internals" of a object (of any part of our API)
should be abstracted out into a separate interface.
I'm thinking of  methods like getBasePointer() or getImageSections()   these
methods are useful if the underlying dump has data it can and wants to share
-  but it possible that the internal information promised by these methods
is just not there.     I think it would be best to extact those methods that
allow peeking inside these objects into a new interface.   Then if an
implementation can provide the data then it only has to return objects which
implement this "peek" interface.   That removes the need to force dumps that
can't respond sensibly to fake stuff and generally makes the API more
consistant.

Not sure how clear that is , when I get another moment I'll post a code
example.


 Cheers

Steve

> -
>
> 2009/8/21 Steve Poole <sp...@googlemail.com>:
> > Hi all,   I've just posted the final version of the first EDR to the wiki
> > here http://cwiki.apache.org/KATO/jsr326specification.html      I'm
> going to
> > just check that I have everything in order process wise and then I'm
> going
> > to send that doc to the JCP as our first EDR.
> >
> > If I've got all the JCP process stuff right then it will take a couple of
> > days for it to appear on the JCP website here
> > http://jcp.org/en/jsr/detail?id=326
> >
> > In theory that is the point where the specification becomes public but
> since
> > we've always had an open approach that's not true for us.   I will be
> > expecting comments from the public to appear on this mailing list.
> >
> > I'll point out again that the EDR is not complete - there are quite a few
> > places where we need to resolve questions and expand the descriptions.
> >
> > Please take a look and comment  - or even provide some more words :-)
> >
> > Cheers
> >
> > Steve
> >
>
>
>
> --
> Regards
>
> Adam Pilkington
>

Re: Final version of First Early Draft Review document

[Adam Pilkington <pi...@googlemail.com>]

I'm currently reading through the EDR, so I'll post my comments ad-hoc
as I progress.

I'm looking at the CorruptData interface and wonder if the
getAddress() method should be renamed so that there isn't a clash with
other getAddress() methods. The reason for this is that if you wanted
to use generics at some point, then when an iterator wants to return a
corrupt object it would do so by returning one that additionally
implemented the CorruptData interface. However this could lead to a
clash e.g. ImageSymbol.getAddress() and CorruptData.getAddress() for
an object which was representing a corrupt ImageSymbol, and care would
need to be taken in order to ensure that you are working with the
correct method.

Given that CorruptData can be implemented by any object, would it be
better to ensure that it uses unique method/field names to prevent
confusion and increase code clarity ?
-

2009/8/21 Steve Poole <sp...@googlemail.com>:
> Hi all,   I've just posted the final version of the first EDR to the wiki
> here http://cwiki.apache.org/KATO/jsr326specification.html      I'm going to
> just check that I have everything in order process wise and then I'm going
> to send that doc to the JCP as our first EDR.
>
> If I've got all the JCP process stuff right then it will take a couple of
> days for it to appear on the JCP website here
> http://jcp.org/en/jsr/detail?id=326
>
> In theory that is the point where the specification becomes public but since
> we've always had an open approach that's not true for us.   I will be
> expecting comments from the public to appear on this mailing list.
>
> I'll point out again that the EDR is not complete - there are quite a few
> places where we need to resolve questions and expand the descriptions.
>
> Please take a look and comment  - or even provide some more words :-)
>
> Cheers
>
> Steve
>



-- 
Regards

Adam Pilkington