[PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK

[Patrick Reinhart]

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 <jbluettduncan at 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.holmes at 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
>>> 
>>>