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

Chris Hegarty chris.hegarty at oracle.com
Wed Mar 12 14:27:49 UTC 2014

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.


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

More information about the core-libs-dev mailing list