RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Stephen Colebourne scolebourne at joda.org
Tue Oct 4 23:10:21 UTC 2016

On 4 October 2016 at 23:27, Stuart Marks <stuart.marks at oracle.com> wrote:
> 4) The 'resolverFields' problem/comment was regarding DateTimeFormatter (see
> this part of latest webrev), where I realised I couldn't use Set.of instead
> of Collections.unmodifiableSet(new HashSet<>(Arrays.asList(*))), because I
> noticed that one of the java.time tests was testing whether
> DateTimeFormatter.withResolverFields(TemporalField...) could accept null
> parameters, which made using Set.of impossible since it's null-hostile (as
> in it throws NullPointerException upon being constructed with null
> element(s)).
> Hm, yes, it's odd that there's a test for an array containing a null, in
> addition to an empty array and a null array. See:
> jdk/test/java/time/tck/java/time/format/TCKDateTimeFormatter.java
> test_resolverFields_listOfOneNull()
> I'm not entirely sure what's intended here. In any case, let's wait until we
> hear from Mr. Colebourne.

I don't think that is a sensible test. AFAICT, null in the set has no
meaning. Its not documented to have meaning, so it is really a bug
with a test.

> 5) For the changes in the Chronology classes, the era() method now returns
> an immutable array where it didn't before. (The List returned by
> Arrays.asList() can have individual elements modified but its size can't be
> changed.) The spec for eras() says "may be immutable" so presumably this is
> OK. But note, since the returned List is now immutable, a new instance
> needn't be created each time. I'm not sure whether it's worth keeping around
> a cached copy in case someone calls eras() again though.
> It would be good if we could hear from Stephen on this one as well.

eras() will rarely be used, so no point caching. Changing to List.of() is fine.


More information about the core-libs-dev mailing list