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

[Stephen Colebourne]

I am happy for the tests to be located in the test.java.time package
rather than the tck.java.time package when backported. However, the
original (broken) TCK tests will need to be removed in that scenario.

I also do not know exactly how the TCK tests feed into the actual TCK
at this point.

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
>>
>>
>