On 08/06/16 15:35, Roger Riggs wrote:
Yes, I would update the spec to the new behavior.
What about:
* <li>Otherwise, if the string contains {@code "{<digit>"}
* where {@code <digit>} is in {@code [0-9]}
* then java.text.MessageFormat is used to format the string.
-- daniel
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
