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

Jonathan Bluett-Duncan jbluettduncan at gmail.com
Fri Sep 30 13:57:44 UTC 2016

Hi Stuart,

Thanks for doing such a thorough review of the parts you've managed to look
at so far.

I see you had a number of questions in your numbered bullet points, so I'll
do my best to answer them below.

1) It actually didn't occur to me that there was a potential TOCTOU problem
in ModuleFinder.compose, despite the fact that I found a potential problem
in FileTreeIterator - it completely missed me, so thank you for finding it!
I'll see if I can put a similar comment there to what I wrote in

2) I seem to remember doing an at least semi-thorough search of the JDK
codebase, and coming to the conclusion that none of the code I touched was
being serialized by the JDK itself. I think I mentioned this is a previous
email, but I also remember saying that I wasn't sure if I took everything
into account, as I'm not that familiar with serialization. So I decided
just now to do a search on Grepcode for usages of CookieManager.get
and curiously it looks like they're only used in sun classes in the JDK. So
this change seems safe to me, unless I've missed something?

Regarding code search engines, I know of sourcegraph.com, but I think it
requires an account to use their service, and I don't know which
repositories they index apart from GitHub.

3) In my local copy of jdk9, I've removed the TOCTOU comment in
FileTreeIterator and changed List.of back to Arrays.asList, as your
explanation regarding FileTreeWalker has convinced me that TOCTOU is not a
real problem here, and I don't know if future memory improvements to
List.of(T...) (like returning an ImmutableCollections.List1 when there's
only 1 element) are worth the extra time spent copying into a new list.

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

So I never did submit a change with that bit of code replaced with Set.of.
Instead I wrote a comment in the method explaining why one can't use
Set.of. I don't really know if Stephen Colebourne saw that comment, though.

Stephen Colebourne, are you still fine with all the changes I've made to
the java.time classes? http://cr.openjdk.java.net/~reinhapa/reviews/8134373/

Kind regards,

P.S. I'll wait until everything's reviewed before asking for a new webrev.

More information about the core-libs-dev mailing list