multiline: .unescape() means it's no longer a compile-time constant.

[Remi Forax]

yes, that's true.

This can be solved by JEP 303 [1] which extends the ways to express constant for the compiler. 
Or shameless plug, you can use one of the exotic classes [2] to make the result of .unescape() constant for the JIT (no for the interpreter) so you keep good perf.

Rémi


[1] http://openjdk.java.net/jeps/303
[2] https://github.com/forax/exotic

----- Mail original -----
> De: "Reinier Zwitserloot" <reinier at zwitserloot.com>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Mercredi 28 Février 2018 07:07:07
> Objet: multiline: .unescape() means it's no longer a compile-time constant.

> # .unescape() won't work if you need a compile time constant. #
> A raw string has the benefit of being a compile time constant. Calling a
> method on a raw string removes this property. For example, the way the
> class file encodes the field between FOO and BAR in this:
> 
> Test.java> class Test {
> static final String FOO = "Hello!";
> static final String BAR = "Hello!".toLowerCase();
> }
> 
> cmdline> javac Test.java; javap -c Test
> 
> is _wildly_ different, and it's not just for efficiency (speed/size) sake
> that this is important: The annotation system, for example, requires CTCs.
> Therefore, calling .unescape() on a literal means a bunch of use cases for
> string literals are eliminated, leaving someone looking for a not-raw
> multiline literal entirely out of luck. A way to indicate multiline and raw
> separately would solve this issue.
> 
>  --Reinier Zwitserloot