+1
Naoto
On 1/22/18 10:15 PM, Rachna Goel wrote:
Hi,
Kindly review updated patch for this doc fix:
patch: http://cr.openjdk.java.net/%7Ergoel/8146656/webrev.02/
Approved CSR : https://bugs.openjdk.java.net/browse/JDK-8191414
Thanks,
Rachna
On 20/12/17 10:44 PM, joe darcy wrote:
Hi Rachna,
I think the revised version with the @implSpec tag switch is
acceptable, but also think providing more text to describe this
situation would be helpful to programmers unaware of a 13 month
possibility.
Cheers,
-Joe
On 12/19/2017 2:08 AM, Rachna Goel wrote:
Hi Joe,
Thanks for the comments.
I have updated the CSR to have @implSpec in place of @implNote.
https://bugs.openjdk.java.net/browse/JDK-8191414
Regarding "An array with either 12 or 13 elements will be returned
depending on whether or {@link Calendar.UNDECIMBER} is supported." ,
I would like to go with existing statement as this method always
returns 13 elements where the 13th element may be empty string or may
contain Calendar.UNDECIMBER, depending upon whether its supported by
the Calendar instance.
kindly suggest whether this looks fine!
Thanks,
Rachna
On 19/12/17 2:55 PM, joe darcy wrote:
Hi Rachna,
On 12/19/2017 1:13 AM, Rachna Goel wrote:
Hello Joe,
Thanks for the review.
Reason I added @implNote is that it's the case for the default
implementation. Not added as a part of spec, as some implementation
can just return 12 element array for same methods through the
"java.text.spi.DateFormatSymbolsProvider" SPI.
That is precisely the sort of situation the @implSpec tag is
intended for. It allows the specification to say DateFormatSymbols
must behave this way while allowing subclasses to behave differently.
Perhaps some general text can be added as normal specification,
something like
"An array with either 12 or 13 elements will be returned depending
on whether or {@link Calendar.UNDECIMBER} is supported."
paired with
@implSpec This method returns 13 elements since @link
Calendar.UNDECIMBER} is supported.
HTH,
-Joe
--
Thanks,
Rachna
--
Thanks,
Rachna
