RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

[nadeesh tv]

Hi Stephen,

Thanks for the comments.
Please see the updated webrev 
http://cr.openjdk.java.net/~ntv/8031085/webrev.01/

--
Thanks and Regards,
Nadeesh TV




On 4/18/2016 3:03 AM, Stephen Colebourne wrote:
> The updated spec at line 670 is not clear - the adjacent parsing mode
> only applies when in strict mode. Suggest a new sentence before the
> lenient mode one: "In strict mode, if the minimum and maximum widths
> are equal and there is no decimal point then the parser will
> participate in adjacent value parsing, see {@code
> appendValue(java.time.temporal.TemporalField, int)}.
>
> Line 2968 is missing a blank line
>
> Line 3001 does not need == true on isStrict() == true
>
> Perhaps line 3004 should return false? I'm not sure what is gained by
> calling super.
>
> The changes to the test cases look wrong.
>
> test_adjacent_lenient_fractionFollows_2digit() and
> test_adjacent_lenient_fractionFollows_0digit() should not have
> changed, as the nano-of-second parsing is in lenient mode, and thus
> should still parse from zero to nine digits.
>
> thanks
> Stephen
>
>
> On 13 April 2016 at 21:46, nadeesh tv <nadeesh.tv at oracle.com> wrote:
>> HI all,
>>
>> BUG ID : https://bugs.openjdk.java.net/browse/JDK-8031085
>>
>> Webrev : http://cr.openjdk.java.net/~ntv/8031085/webrev.00/
>>
>> Issue - Fractional parts of seconds do not participate in the protocol for
>> adjacent value parsing
>>
>> Solution - Changed the FractionPrinterParser to subclass of
>> NumberPrinterParser to make it participate in adjacent value parsing
>>
>>   2 existing test cases
>> TCKDateTimeFormatterBuilder.test_adjacent_lenient_fractionFollows_0digit and
>> test_adjacent_lenient_fractionFollows_2digit were failing. Changed them
>> accordingly.
>>
>> --
>> Thanks and Regards,
>> Nadeesh TV
>>

-- 
Thanks and Regards,
Nadeesh TV