Looks good. Stephen
On 19 April 2016 at 09:42, nadeesh tv <nadeesh...@oracle.com> wrote: > 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...@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 >
