RFR: 8153666: Optimize Formatter.formatMessage

[Roger Riggs]

Yes, I would update the spec to the new behavior.


On 6/8/2016 10:31 AM, Daniel Fuchs wrote:
>
> Good point Roger!
>
> I was already wondering whether looking for {[0-9] instead
> of {[0-3] deserved a small mention in the release note.
>
> The fact that the spec needs updating confirms that this
> little behavior change probably needs to be mentioned.
>
> I will do the paperwork for the spec change.
> I don't think we need any switch to revert to the old behaviour,
> right?
>
> best regards,
>
> -- daniel
>
>
> On 08/06/16 15:14, Roger Riggs wrote:
>> Hi Daniel,
>>
>> Looks ok, but...
>>
>> Formatter.java:
>>
>> - line 104: the javadoc says it looks for '{0'  but the implementation
>> looks for '{'[0..9]
>>   It looks like the spec is out of sync with the implementation (the
>> implementation is more lenient)
>>   and has been for a while.
>>
>>   According to the spec/javadoc; no formatting should occur unless it
>> contains "{0"
>>
>> Roger
>>
>>
>> On 6/8/2016 9:46 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a patch for a small optimization
>>> in Formatter.formatMessage.
>>> This patch also removed the synchronized keyword which
>>> was there for historical reasons - but which has
>>> become needless.
>>>
>>> More background available at:
>>> https://bugs.openjdk.java.net/browse/JDK-8153666
>>> (thanks Martin!)
>>> and
>>> http://stackoverflow.com/questions/36433146/why-is-the-formatmessage-method-in-java-util-logging-formatter-synchronized 
>>>
>>>
>>> (thanks Jason!)
>>>
>>> bug:
>>> 8153666: Optimize Formatter.formatMessage
>>> https://bugs.openjdk.java.net/browse/JDK-8153666
>>>
>>>
>>> patch:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8153666/webrev.00
>>>
>>> best regards, and thanks to all who provided suggestions and
>>> archeological background!
>>>
>>> -- daniel
>>
>