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

Remi Forax forax at
Wed Feb 28 13:34:56 UTC 2018

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.



----- Mail original -----
> De: "Reinier Zwitserloot" <reinier at>
> À: "amber-dev" <amber-dev at>
> 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:
>> class Test {
> static final String FOO = "Hello!";
> static final String BAR = "Hello!".toLowerCase();
> }
> cmdline> javac; 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

More information about the amber-dev mailing list