Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8286021

Implementation of JEP 430 String Templates (Preview)

    XMLWordPrintable

Details

    • CSR
    • Status: Closed
    • P3
    • Resolution: Approved
    • 21
    • tools
    • None
    • source
    • minimal
    • Hide
      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.
      Show
      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.
    • Java API
    • SE

    Description

      This is the CSR for the implementation of JEP-430 String Templates (Preview)

      Summary

      Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a preview language feature and API.

      Problem

      Injecting values into strings using the Java + string operator can often lead to unreadable code and code that is prone to errors and/or injection attacks.

      Solution

      JEP-430 String Templates (Preview) introduces string templates which will allow users to inject values into a String in situ. The use of string templates versus string interpolation allows for a richer feature that, in addition to composition, allows validation and non-string result transformations.

      Specification

      The following APIs were added:

      The static field STR declared in java.lang.StringTemplate is imported automatically into every Java program, as if the declaration import static java.lang.StringTemplate.STR; appeared at the beginning of each compilation unit immediately after any package declaration. (In JDK releases where the String Templates feature is in preview, the automatic importing occurs only if preview features are enabled.)

      The static field RAW which is also declared in java.lang.StringTemplate is not imported automatically imported every Java program.

      The following APIs were modified:

      Attachments

        1. api.zip
          734 kB
        2. api-1.zip
          734 kB
        3. api-10.zip
          737 kB
        4. api-11.zip
          728 kB
        5. api-12.zip
          728 kB
        6. api-13.zip
          728 kB
        7. api-14.zip
          729 kB
        8. api-15.zip
          729 kB
        9. api-16.zip
          729 kB
        10. api-17.zip
          729 kB
        11. api-18.zip
          733 kB
        12. api-19.zip
          734 kB
        13. api-2.zip
          734 kB
        14. api-20.zip
          734 kB
        15. api-21.zip
          734 kB
        16. api-22.zip
          734 kB
        17. api-3.zip
          734 kB
        18. api-4.zip
          735 kB
        19. api-5.zip
          736 kB
        20. api-6.zip
          736 kB
        21. api-7.zip
          737 kB
        22. api-8.zip
          737 kB
        23. api-9.zip
          737 kB

        Issue Links

          Activity

            People

              jlaskey Jim Laskey
              jlaskey Jim Laskey
              Alex Buckley, Roger Riggs, Vicente Arturo Romero Zaldivar
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: