Hi Jonathan, As just also wanted to help some more clean-up in the JDKs final phase, I could offer you to hold that patch. Just send it to me and I will prepare the webrev for you….
-Patrick > Am 12.09.2016 um 20:36 schrieb Jonathan Bluett-Duncan > <jbluettdun...@gmail.com>: > > Hi David, > > Thanks for letting me know about the attachment stripping behaviour, and > reminding me about the current state of the JDK 9 release schedule. > > Stuart, would you be happy to host my patch on cr.openjdk.java.net? If not, > do you know who else might be happy to host it for me? Or alternatively, > would you prefer I wait until development of Java 9 Updates and/or Java 10 > starts? > > Kind regards, > Jonathan > > On 12 September 2016 at 01:50, David Holmes <david.hol...@oracle.com> wrote: > >> Hi Jonathon, >> >> Attachments get stripped from most of the mailing lists so you will need >> to find someone to host these for you on cr.openjdk.java.net. >> >> That aside you may be hard pressed to find anyone who can look at this >> future work now, given where things are with the JDK 9 release schedule. >> >> Cheers, >> David >> >> >> On 11/09/2016 9:42 AM, Jonathan Bluett-Duncan wrote: >> >>> Hi all, >>> >>> Would you kindly review this patch to replace existing uses of >>> Collections.unmodifiable*(*Arrays.asList(*)) and plain Arrays.asList(*) >>> with (List|Set|Map).of(*). You may find the patch files in the >>> attachments. >>> >>> My rationale for replacing uses of Collections.unmodifiable*... with >>> (List|Set|Map).of is to make use of the memory savings allowed by the >>> newer >>> APIs. >>> >>> The general rationale for replacing the Arrays.asList calls I've touched >>> is >>> to again make use of memory savings, but this may be naive or misguided >>> reasoning on my part, as Arrays.asList may or may not be more >>> memory-efficient than List.of. However, where I've replaced Arrays.asList >>> for List.of in FileTreeIterator, my reasoning for doing so instead was to >>> help prevent TOCTOU attacks, but again this may be misguided on my part. >>> >>> It doesn't seem practical to me to include new unit tests, as these are >>> mainly performance improvements, but if it's believed that new unit tests >>> are needed, then I'd be happy to go back and try to include some. >>> >>> Kind regards, >>> Jonathan >>> >>>
