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

[Stephen Colebourne]

To confirm, this counts as a review "yes"?
Stephen


On 12 March 2014 14:27, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 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
>>
>>
>