Raw String Literals Java

3

I saw that in JDK 12 it is possible to make raw string literals similar to some programming languages like C #, JS, R etc.

Ex in C #:

"Essa não é uma \n raw string";

Output:

Essa não  é uma
 raw string
@"Essa é uma \n raw string";

Output:

Essa é uma \n raw string

My question is: how to use this feature in JDK 12?

    
asked by anonymous 28.11.2018 / 05:15

1 answer

3

Using the JDK 12

Before starting the actual response, as requested in the question "how to use this feature in jdk 12?", it is best to first indicate how to access JDK 12 and use it.

To download the latest build, visit the link page and download the build to the platform of your choice. Note that there are features in early access (EA), and that features that are not stable enough will not go to general availability (GA)

So if you're planning to use some new JDK 12 functionality in production, be aware to see if it has gone from the EA phase and is ready for GA. Otherwise, it will not be available in the final build (GA).

The proposal for raw strings

According to JEP 326 , which contains this proposal, simply use ticks (the character "'", also known as grave accent).

The biggest change in this JEP is in the Java grammar, changing the literal specification contained in the §3.10 of JLS . The change was to add a further production of the non-terminal Literal and the productions of the new non-terminal, RawStringLiteral .

  

Old BNF:

Literal:
    IntegerLiteral
    FloatingPointLiteral
    BooleanLiteral
    CharacterLiteral
    StringLiteral
    NullLiteral
     

New BNF:

Literal:
    IntegerLiteral
    FloatingPointLiteral
    BooleanLiteral
    CharacterLiteral
    StringLiteral
    RawStringLiteral
    NullLiteral
     

Productions related to RawStringLiteral introduced:

RawStringLiteral:
    RawStringDelimiter RawInputCharacter {RawInputCharacter} RawStringDelimiter
RawStringDelimiter:
    ' { ' }
     

Note:

     

At the JLS BNF, everything inside keys is subject to the Kleene Star; so, "' { ' } " would equal the regex "''*" , tick , Kleene star * )

Read more about grammars and BNF:

Examples, each string ending with a ; :

'tem uma contrabarra no fim\';
''com dois ticks abrindo, posso por 'tick' no meio da frase a vontade'';
'''se abro com n ticks, fecho com os mesmos n ticks''';
'pode fazer
 múltiplas
 linhas se assim
 desejar';
'no final da frase não quebro a linha\n';

To interpret these escapes in the traditional way, you have the instance method unescape . So the following Java code

String ex = 'uma frase
outra frase\ne por fim!';
System.out.println("1:" + ex + ":1");
System.out.println("2:" + ex.unescape() + ":2");

prints the following lines:

1:uma frase
outra frase\ne por fim!:1
2:uma frase
outra frase
e por fim!:2

A raw string differs from a traditional string of source code writing, and is a standard string for the JVM. Therefore, JEP has added a new compiler function (identifying the ticks for raw string) and the String.unescape() instance method already described here. There are other additional methods that JEP proposes, which focuses on sloth aesthetics of code with raw strings. I will not go into detail, but I will enumerate the new String methods I found in JEP (all are instance methods):

  • String unescape() (already cited)
  • String align()
  • String align(int)
  • String indent(int)
  • <R> R transform(Function<String, R> f)

It should be noted that this JEP is a preview language feature , which, as defined in JEP 12 a> is placed as a temporary feature to provoke discussion and analyze impacts on the programmer's life in his or her real environment.

Criticism of JEP 326 by me

The first point I found strange, very strange, is that in the writing of this JEP the String.length attribute was used, whereas I only knew the String.length() method. You even have a discussion about this .

boolean b2 = '\n'.length == 2;

I even looked for changes to this in the JDKs of the JDKs 10 and 11, just as I took a look at the JDK 9 changes, but I did not find anything to do with it, because% has become an < strong> or a syntactic sugar so you do not need the parentheses. I did not find it, though I would be grateful if it happened.

The other point is that when comparing with literal strings / raw strings from other platforms, they put it in Python with just triple quotes , when in fact they are started with .length .

"""...""" Groovy, Kotlin, Python, Scala, Swift
     

Python, Kotlin, Groovy and Swift have opted to use triple double quotes to indicate raw strings.

Triple triangles in Python actually serve for multi-line strings .

So, it seems to me that this JEP had a lack of zeal as compared to Python, and that the absence of parentheses in the r" method was by programmer mania (or else being a feature that came in and I could not notice its appearance).

    
28.11.2018 / 06:34