Hi Aleks,
Sorry for not responding but what I tried to say is that with your code
you are still creating a instance of Supplier which could be avoided by
changing the code to use a BiFunction
Take
"src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java"
as a example.
You changed the code to:
---
private static void debugPrintln(Supplier<String> msgGen) {
if (DEBUG) {
System.err.println("JAXP: " + msgGen.get());
}
}
...
debugPrintln(()->"created new instance of " + providerClass +
" using ClassLoader: " + cl);
---
If you'd use a BiFunction you would not need to capture "providerClass"
and "cl" hence only one single instance is created.
---
private static void debugPrintln(Object o1, Object o2,
BiFunction<Object,Object,String> msgGen) {
if (DEBUG) {
System.err.println("JAXP: " + msgGen.apply(o1,o2));
}
}
...
debugPrintln(providerClass, cl,
(o1,o2) ->
"created new instance of " + o1 + " using ClassLoader: " + o2
);
---
Whether this makes sense depends on how frequently this code is run.
Tom
On 15.12.16 21:45, Aleks Efimov wrote:
> Hi Tom,
>
> The main purpose of this fix is to postpone debug message string parts
> calculation/concatenation till when the actual output is needed, i.e. we
> don't want to call which(clazz) until the debug output is needed
> (debug=true) in XPathFactoryFinder ). I'm not sure that
> function/bifunction can give us such possibility due to different ways
> of messages construction in dPrint and debugPrintln usages.
>
>
> Best,
> Aleksej
>
> On 15/12/16 20:22, Tom Schindl wrote:
>> 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.efi...@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
>>>>>
>
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
