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