On Fri, 3 Mar 2023 19:42:53 GMT, Roger Riggs <[email protected]> wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Tighten up reporting of string template errors (fewer messages)
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 66:
>
>> 64: * <p>
>> 65: * {@link FormatProcessor} format specification uses and exceptions are
>> the same as
>> 66: * those of {@link Formatter}.
>
> Suggestion:
>
> * The {@link FormatProcessor} format specification uses and exceptions are
> the same as
> * those of {@link Formatter}.
Changing.
> src/java.base/share/classes/java/util/FormatProcessor.java line 134:
>
>> 132: * format string from the fragments, gathers up the values and
>> 133: * evaluates the expression
>> 134: * {@code new Formatter(locale).format(format, values).toString()}.
>
> Should this be described using the "as if"... phrasing to avoid a literal
> requirement in the spec that is inflexible?
Changing
> src/java.base/share/classes/java/util/FormatProcessor.java line 175:
>
>> 173: * {@link FormatProcessor#FMT} ({@code static final
>> FormatProcessor}).
>> 174: * <p>
>> 175: * Other {@link FormatProcessor} can be specialized if stored as
>> static final.
>
> Suggestion:
>
> * Other {@link FormatProcessor}s can be specialized if stored as a
> static final.
Changing
> src/java.base/share/classes/java/util/FormatProcessor.java line 187:
>
>> 185: * @throws IllegalFormatException
>> 186: * If a format specifier contains an illegal syntax, a
>> format
>> 187: * specifier that is incompatible with the given arguments,
>
> Suggestion:
>
> * specifier is incompatible with the given arguments,
Existing statement is consistent with those in Formatter. Reads more correctly
as is.
-------------
PR: https://git.openjdk.org/jdk/pull/10889
