<i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v30]
Roger Riggs
rriggs at openjdk.org
Wed Nov 23 17:30:03 UTC 2022
On Wed, 23 Nov 2022 16:40:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
>> src/java.base/share/classes/java/util/FormatProcessor.java line 85:
>>
>>> 83:
>>> 84: /**
>>> 85: * {@inheritDoc}
>>
>> The javadoc should describe in more detail what `process` does and the errors than can occur.
>> That will help developers understand the errors that come out of Formatter in the context of FMT.
>> That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed.
>> The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment.
>> For example, if multiple format strings appear in the fragment they are all passed to Formatter.
>> If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value. For example,
>>
>> int x = 1;
>> FMT."x: %s {x}"; // extra space
>>
>> It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument. That's exposing the implementation and may look like a bug in the FMT.
>
> Will clean up javadoc for FormatProcessor::process.
>
> It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually.
Since FormatProcessor is scanning for format strings (in stringTempateFormat), it could check for the wrong number and misplaced format strings and throw. It would make the exception more specific to the arguments to the FMT.process() and easier for the developer to correct.
-------------
PR: https://git.openjdk.org/jdk/pull/10889
More information about the i18n-dev
mailing list