RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null (original) (raw)
Chris Hegarty chris.hegarty at oracle.com
Wed Mar 12 14:27:49 UTC 2014
- Previous message: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null
- Next message: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null
- Next message: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]