RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null

[Chris Hegarty]

The change look ok to me too.

There is a change in behavior here, but I don't expect it to be 
surprising ( no NPE where there once was ), so I think it should be fine 
for 8u-dev also.

The TCK test changes however, may not be suitable for 8u. Though I'm not 
sure how these tests feed from the OpenJDK repo into the actual TCK.

-Chris.

On 12/03/14 13:54, roger riggs wrote:
> Looks fine,  (not a reviewer).
>
> I can sponsor the fix when reviewed.
>
> Thanks, Roger
>
> On 3/12/2014 6:45 AM, Stephen Colebourne wrote:
>> This is a request for review of this bug:
>> https://bugs.openjdk.java.net/browse/JDK-8036818
>>
>> The method DateTimeFormatter withResolverFields() is supposed to
>> accept null. This is to allow a coy of the formatter to be returned
>> reset to the original state of having no resolver fields. The docs
>> say:
>> "@param resolverFields the new set of resolver fields, null if no fields"
>> which was written to indicate that resetting to null is permitted.
>>
>> The fix is to check for null and return a copy of the formatter. Note
>> that there are two variations of the method which need fixing.
>>
>> Proposed patch:
>> https://gist.github.com/jodastephen/9395197
>> The patch includes no spec changes.
>> The patch fixes the broken TCK tests.
>>
>> I need a reviewer and a committer please.
>> thanks
>> Stephen
>