This is part of the preview feature String Templates. The new APIs do not conflict with existing APIs or behaviour and do not require any class file changes. The change to automatically import the static field `STR` in every Java program is not 100% source compatible. Two examples, each of which is expected to be extremely rare: 1. Suppose a program previously brought the simple name `STR` into scope via an explicit static-import-on-demand declaration `import static foo.bar.*;` (where the class `foo.bar` declares a static field `STR`). The explicit declaration will be shadowed by the automatic single-static-import declaration `import static java.lang.template.StringTemplate.STR;`, such that the simple name `STR` now refers to a `StringProcessor` and not whatever `foo.bar.STR` is. The program will have to be changed to use the qualified name `foo.bar.STR` -- and depending on what else is in class `foo.bar`, the explicit `import static foo.bar.*;` may now be redundant. 2. Suppose a program previous brought the simple name `STR` into scope via an explicit single-static-import declaration `import static foo.bar.STR;`. Any use of the simple name `STR` will now produce a compile-time error. This is due to ambiguity: the program also declares `import static java.lang.template.StringTemplate.STR;` and neither declaration of the field `STR` shadows the other. The program will have to be changed to use the qualified name `foo.bar.STR` or `java.lang.template.StringTemplate.STR` as appropriate. The explicit `import static foo.bar.STR;` is effectively redundant.