JDK-8203630 : String::formatted (Preview)
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 13
  • Submitted: 2018-05-22
  • Updated: 2019-06-04
  • Resolved: 2019-06-04
Related Reports
CSR :  
Relates :  
Relates :  
Description
Summary
-------

Introduce instance versions of the existing String::format method.

This will be a [preview language feature](http://openjdk.java.net/jeps/12) as part of [Text Blocks](https://bugs.openjdk.java.net/browse/JDK-8222530)

Problem
-------

The static forms of String::format lack a flowiness that is expected in modern Java code. Text Blocks significantly emphasize this condition.

Example:

```
        String type = "Integer";
        String variable = "value";
        
        String source = String.format("""
                        public void print(%s %s) {
                            System.out.println(Objects.toString(object));
                        }
                        """, type, variable);
```

In this example, the format is not the focus of the expression, and the argments are near invisible,

Solution
--------

Provide instance versions of format methods.

```
        String type = "Integer";
        String variable = "value";
        
        String source = """
                        public void print(%s %s) {
                            System.out.println(Objects.toString(object));
                        }
                        """.formatted(type, variable);

```

Using String instance "format" splits focus more clearly into 1) the format and 2) the arguments.

Due to method overloading lookup, this solution also requires a unique name other than "format". Hence, the name "formatted".

Alternatives
------------

The argument for implementing ` String::format ` as static appears to be that the format methods could be imported statically and thus conduct themselves comparably to C's ` sprintf ` .

```
import static java.lang.String.format;
...
        int result = 10;
        String str = format("This result is %d", result);
```

However, developers use imported static infrequently and are forced, somewhat redundantly, to add the class selector.

```
        int result = 10;
        String str = String.format("This result is %d", result);
```

Specification
-------------

```
    /**
     * Formats using this string as the format string, and the supplied
     * arguments.
     *
     * @implSpec This method is equivalent to {@code String.format(this, args)}.
     *
     * @param  args
     *         Arguments referenced by the format specifiers in this string.
     *
     * @return  A formatted string
     *
     * @see  java.lang.String#format(String,Object...)
     * @see  java.util.Formatter
     *
     * @since 13
     *
     * @deprecated  This method is associated with text blocks, a preview language feature.
     *              Text blocks and/or this method may be changed or removed in a future release.
     */
    @Deprecated(forRemoval=true, since="13")
    public String formatted(Object... args) {
        return new Formatter().format(this, args).toString();
    }
```
Comments
Moving to Approved.
04-06-2019

Made minor suggested change to text of implSpec tag.
31-05-2019

https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053403.html
30-05-2019

I would also advise removing the throws clauses for the unchecked exceptions has they should be implied by the @implSpec note. If there is sufficient cause to add these methods without text block, the Deprecated annotation could be removed. (I'm still not completely sold on these methods.) Moving to Provisional.
24-05-2019

I had already migrated to i -> locale in the code, was just waiting for more input before further changes. Will change doc to refer to subordinate methods.
24-05-2019

I acknowledge that the existing format���(Locale l, String format, Object... args) using "l" was a parameter name. However, this is bad practice and unnecessary; I offer "locale" as an alternative. If these methods are to be added as instance rather than static version of the format functionality, I would much prefer to the bulk of the specs be repeated once rather than copy and pasted. Toward this end, I would strongly recommend a primary spec as @implSpec "This method is equivalent to String.format(this ...)" rather than duplicating dozens of line of specification.
24-05-2019

Now part of the Text Blocks discussion.
13-05-2019

Dan, Please drive the discussion of giving priority of instance methods over static methods. Reassign to me when the decision is made.
05-02-2019

I must admit that I am not convinced that this change is either necessary or helpful. I will advance this request to Provisional, but I expect multiply reviewers and significant consensus on the utility of this change before it will be Approved.
25-09-2018