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

Chris Hegarty chris.hegarty at oracle.com
Mon Mar 17 13:58:09 UTC 2014

On 17 Mar 2014, at 11:17, Stephen Colebourne <scolebourne at joda.org> wrote:

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

Yes. Sorry if this wasn't clear.

-Chris.

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

More information about the core-libs-dev mailing list