RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance
Tom Schindl
tom.schindl at bestsolution.at
Thu Dec 15 17:22:43 UTC 2016
Wouldn't it be better to use a function/bifunction instead of a supplier because the supplier is a capturing?
Tom
Von meinem iPhone gesendet
> Am 14.12.2016 um 19:04 schrieb Aleks Efimov <aleksej.efimov at oracle.com>:
>
> Hi Joe,
>
> Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier<String>' instead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be illustrated by this webrev:
> http://cr.openjdk.java.net/~aefimov/8146271/9/01
>
> Best Regards,
> Aleksej
>
>
>> On 14/12/16 03:35, Joe Wang wrote:
>> Hi Aleksej,
>>
>> You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) where similar problems exist.
>>
>> Best,
>> Joe
>>
>>> On 12/13/16, 3:02 PM, Aleks Efimov wrote:
>>> Hello,
>>>
>>> Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block:
>>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/
>>>
>>> Best Regards,
>>> Aleksej
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271
>>>
>
More information about the core-libs-dev
mailing list