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 FileTreeIterator. 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 <http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root@jdk%24openjdk@8u40-b25@java%24net@CookieManager@get%28java.net.URI%2Cjava.util.Map%29&k=u> and CookieHandler.get <http://grepcode.com/search/usages?id=repository.grepcode.com$java$root@jdk$openjdk@8u40-b25@java$net@CookieHandler@get%28java.net.URI,java.util.Map%29&start=0&r=&type=method&k=u>, 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 <http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01/src/java.base/share/classes/java/time/format/DateTimeFormatter.java.cdiff.html>), 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)). 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/ webrev.01/ Kind regards, Jonathan P.S. I'll wait until everything's reviewed before asking for a new webrev.
