Hi Avik,
On 8/23/16 11:43 PM, Avik Niyogi wrote:
Hi Jim,
Just a few queries I have regarding the inputs provided. I have added them
inline in red. Thank you for further inputs
in advance.
On 24-Aug-2016, at 3:02 am, Jim Graham <james.gra...@oracle.com
<mailto:james.gra...@oracle.com>> wrote:
I wonder why the @throws is not inherited...?
Another way to fix this would be to implement it in the base Image class with
the throw and all classes that can
return a graphics override it. Then you wouldn't even need documentation in the
AMRI class just to say "never mind we
don't provide this method”.
AN: According to the bug description as written by the JCK team, they are
expecting a custom synopsis for all
the overridden methods in the AMRI class. Is this absolutely necessary for the
JCK implementation. Is the real reason
that a custom documentation required or is the documentation derived not
available while creating JCK tests and/or they
are not apt descriptions for the JCK tests? Either ways, which way of
documentation of the AMRI class seem most
appropriate and which requirement mention should be given the right precedence?
I don't have answers to your questions, I just know that the documentation that was inherited (which seems to have
missed inheriting the thrown exceptions) contains no mention of the exception that will be thrown here.
I also know that this method is not relevant to this type of image and the fact that we have to override it just to have
it choose the escape clause inherent in the spec is silly. We beg the question by having to implement it and then
explain that we are implementing it only to assert that it can't be implemented. That's a silly situation that should
be instead handled by having the exception be the default implementation on the super class and have only those methods
that can implement the behavior override it.
If we have a concrete implementation in the base Image class then this method doesn't even appear in the documentation
of the AMRI class in the first place (it appears in the list of inherited methods which has the full description).
On the other hand, one could argue that the super class method is sort of vague in describing which types of image
support the method and which do not. In that case, then I think it makes sense for AMRI to override it just to state
its policy on whether one can get a graphics from it. If that is the route we go for this method then I think it makes
sense to mention "why" we are throwing the exception rather than simply state that we are throwing it.
For example:
For the getWidth(ImageObserver observer) method, the description which would
have come in a new webrev would have been
the following.
/**
* Returns the width of the base image. If the width is not yet known,
* this method returns <code>-1</code> and the specified
* <code>ImageObserver</code> object is notified later.
* @param observer an object waiting for the image to be loaded.
* @return the width of this image, or <code>-1</code>
* if the width is not yet known.
*/
Does this look apposite for the AMRI class or does this seem “too custom” for
the worse?
Note that the AMRI class does provide a width and height so it does need to override these methods. Also, the return
values from these methods are special in the case of an AMRI and so the exact behavior needs to be described in these
methods (in particular, that the w/h of the base image is used).
The spec mentions that the method only works for off-screen images. While an
AMRI may contain some off-screen images,
it is not itself an off-screen so it should mention that. If we choose to list
it in the methods in AMRI then I would
just copy the entire comment from the super class Image and edit it based on
the assumption that it is not supported
for off-screen images, something like:
/**
* This inherited method can only be called for off-screen images, and throws
* an exception in classes like this that do not support it.
* @return there is no return value for a non-off-screen image.
* @exception UnsupportedOperationException since this class does not
represent
AN: Is there any particular reason we need to use @exception and not @throws?
Sorry if it seems like a novice question, but when is either one used and why
is @throws not the right tag to use here?
I just copied and pasted from the source code for the Image.getGraphics() method and it used @exception. They are
described as synonyms by the documentation on writing javadocs and I'm not sure whether we prefer one or the other.
Phil might know the answer to that...
...jim
* an off-screen image.
*/
...jim
