JEP canceled
The Openjdk team announced via Twitter in December/2018 that this JEP was canceled from Java 12.
The official reasons were exposed here. It is worth noting that this functionality was removed still in preview Feature, And according to Brian Goetz, the date to become a permanent feature is still doable. Possibly the definitive version is implemented differently to what I described below, mainly because there was a very strong negative reception to the use of tics and, also, the possibility to open with arbitrary amount of tics.
That being said, it is no longer possible to use this functionality in the GA version of Java 12 and therefore get it in order to test this functionality will be in vain.
The answer below remains only for historical interest.
Using the JDK 12
Before beginning the answer itself, as asked 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 page https://jdk.java.net/12/ and download the build to the platform of your choice. Learn 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 looking to use some new functionality from the JDK 12 in production, be on the lookout for whether it’s past the EA stage and ready for GA. Otherwise, it will not be available in the final build (GA).
The proposal for raw strings
According to the JEP 326, which contains this proposal, it is sufficient to use the ticks (the character "`", also known as grave accent).
The biggest change of this JEP is in Java grammar, changing the specification of literals contained in the section §3.10 from JLS. The change was to add one more production of the non-terminal Literal
and the productions of the new non-terminal, the RawStringLiteral
.
BNF old:
Literal:
IntegerLiteral
FloatingPointLiteral
BooleanLiteral
CharacterLiteral
StringLiteral
NullLiteral
BNF new:
Literal:
IntegerLiteral
FloatingPointLiteral
BooleanLiteral
CharacterLiteral
StringLiteral
RawStringLiteral
NullLiteral
Production relating to RawStringLiteral
introduced:
RawStringLiteral:
RawStringDelimiter RawInputCharacter {RawInputCharacter} RawStringDelimiter
RawStringDelimiter:
` { ` }
Note:
At the JLS BNF, everything inside the keys is subject to the Kleene Star; therefore, "` { ` } "
would amount to regex "``*"
(tick, tick, Kleene star *
)
Read more about grammars and BNF:
Examples, each string terminated by one ;
:
`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 make the interpretation of these escapes in a traditional way, has the instance method unescape
. Then, 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 only differs from a traditional string at the level of source code writing, so it is a standard string for the JVM. Therefore, JEP added a new compiler function (identifying the ticks for raw string) and the instance method String.unescape()
already described here. There are other additional methods that JEP proposes, which has as an auxiliary focus the sloth the code aesthetic with raw strings. I will not go into detail, but I will list the new methods of String
I found in JEP (all are instance methods):
String unescape()
(already quoted)
String align()
String align(int)
String indent(int)
<R> R transform(Function<String, R> f)
It is worth noting that this JEP is a preview language Feature, as defined in JEP 12, is placed as a Feature temporary to provoke discussions and analyze impacts on the life of the programmer in their real environment.
Criticism of JEP 326 by me
The first point I found strange, very strange, is that in the writing of this JEP was used the attribute String.length
, whereas I knew only the method String.length()
. There’s even a discussion about it here.
boolean b2 = `\n`.length == 2;
I even looked for changes to this in the Jdks 10 and 11 Jeps, as well as looking over the changes in JDK 9, but I couldn’t find anything related to this, the fact that .length
have become an attribute or a syntactic sugar not to need the parentheses. I did not think, although I would be grateful if this occurred.
The other point is that when comparing with literal strings / raw strings from other platforms, they put that in Python is only with triple quotes, when in fact they are started with r"
.
"""...""" Groovy, Kotlin, Python, Scala, Swift
Python, Kotlin, Groovy and Swift have opted to use triple double Quotes to indicate raw strings.
The triple quotes in Python are actually for multi-line strings.
So it seems to me that this JEP had a lack of zeal in the aspect of comparison with Python, and that the absence of parentheses in the method .length()
was by programmer mania (or else by being a Feature that came in and I couldn’t notice its emergence).
They canceled the entry of this feature in Java 12 =( I updated my reply with this cancellation
– Jefferson Quesado