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

[Xueming Shen]

Stephen,

public DateTimeFormatter withResolverFields(TemporalField... resolverFields) {
- Objects.requireNonNull(resolverFields, "resolverFields");
- Set<TemporalField> fields = new HashSet<>(Arrays.asList(resolverFields));
+ Set<TemporalField> fields = null;
+ if (resolverFields != null) {
+ fields = Collections.unmodifiableSet(new HashSet<>(Arrays.asList(resolverFields)));
+ }
if (Objects.equals(this.resolverFields, fields)) {
return this;
}
- fields = Collections.unmodifiableSet(fields);
return new DateTimeFormatter(printerParser, locale, decimalStyle, resolverStyle, fields, chrono, zone);
} Isn't it better to do

+ if (resolverFields != null && resolverFields.length != 0) {
+ fields = Collections.unmodifiableSet(new HashSet<>(Arrays.asList(resolverFields)));
+ }

(similar size check for the set version) ? -Sherman



On 03/12/2014 03: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