相比于 Java 10 的 var, 更期待 Java 11 支持多行字符串
Java 六个月的版本迭代周期让我们突然间有些喘不过气来，又 Java 11 才会是一个长期支持版本，如果可能的话我们将会是从 Java 8 直接往 Java 11 跳去。本篇原本只是为了对 Java 11 潜在的原始字符串字面量(Raw String Literals)的哨探，同时考虑到 Java 10 仅有的一个语言层面的新特性 var
局部变量类型推断
，所以顺带介绍一下。
我这儿把它称之为 var 局部变量类型推断
，说明了 var
类型推断并不适用于类或实例的变量，或方法的参数。而且 var
也并未上升为一个 Java 的关键字，我们仍然可以用 var
作为变量或方法名。
对局部变量用 var
进行类型推断的代码示例变化如下：
List<String> list = new ArrayList<>(); //Java 10 以前 var list = new ArrayList<String>(); //Java 10 开始 int age = 100; //Java 10 以前 var age = 100; //Java 10 开始，推断为 int 类型 var stream = blocks.stream(); //都不需要引入 java.util.Stream 类
var
学了 Scala
的语法，再重复一遍， var
只能用于局部变量，这有一个好处就是局部变量的跨越性较小，不至于 var
声明的变量阅读时只有编译器知道它的确切类型。 var
类型推断给代码书写上的变化就是对局部变量的任何类型声明都可以替代为 var
。
看到前面的 var
，仿佛觉得它摇身一变就成了 Java 的关键字，其实不然， var
仍然可用作普通的变量或方法名，下面的代码是可以被正常编译执行的
public static void main(String[] args) {
int var = 100;
var(var);
}
private static void var(int var) {
System.out.println(var);
}
简单见识过 Java 10 的 var
后，我们再推进到尚处于愿景中的 Java 11 特性: 原始字符串字面量(Raw String Literals, 含多行字符串，避免转议，heredoc，但不包含字符串插值)。 JEP 326: Raw String Literals
, 仍处于候选状态，相应 Issue 是 JDK-8198986： 3.10.7： Raw string literals
, 活跃当中，优先级是 P3。不管是否能在 Java 11 还是后续的版本中加入，先了解一下这个 JEP 是干什么的。
var
仅让我们免去了书写变量的类型，以不变应万变，仅乎改进体验收效不甚明显，那么 JEP(JDK Enhancement Proposal) 326 将会带我们带来更大的快感。
回顾一下我当年对 Java 的多行字符串是多么的渴望，尝试过用 Java 的编译期 AnnotationProcessor 的方式: Java 的多行字符串 Here Document 的实现 。后来完全对此失望了，Java 对某些众多语言共有便利特性的追逐总是慢了十拍，要多行字符串的时候就直接求助于 Scala 或 Groovy 语言，只是让一个项目变得更复杂了些。
说几个切实的例子，由于 Java 没有多行字符串的表示法，我们在代码中写一段 SQL 语句，JSON 字符串，或 XML 字符串，我们不得不用加号换行连接，还得对其中的双引号进行转议，对正则表达式中的关键字也必须进行双重转议。
String sql = "select id, name /n "
+ " from user /n"
+ " where id=? /n"
+ " and deleteFlag = 0";
String json = "{/n"
+ "/"id/": 123,/n"
+ "/name/": /"Yanbin/"/n"
+ "}";
上面只是一个简单示例，实际项目中的 SQL 或 JSON 会比这个更加庞大，导致大量的连接与转议，书写起来特不方便。也许会说可以在外部先写好，用工具一次性转议即可，但代码要进行修改时又苦了。所以有时候不得不把大段的类似的格式化文本外部化到文件中，只在运行时载入。
如果候选中的 JEP 326 能够成行的话，上面的代码只要写成
String sql = `select id, name
from user
where id=?
and deleteFlag = 0`;
String json = `{
"id": 123,
"name": "Yanbin"
}`;
如果打印它们的话可保持一样的格式输出，是不是有一种所见即所得的即视感？该 JEP 326: Raw String Literals
，描述的是用斜撇号(backtick) 来作为边界符，其中的字符无须进行转议，如果中间有 /n
或 /u2022
, 它们都将以字面量的形式输出，所以才叫做 Raw String Literals
。斜撇号的表示法是参考了 Go, JavaScript 的做法。Scala 或 Groovy 是用三个双引号 """
。
如果字符串字面量中含有斜撇号的话，边界用双重斜撇号，如
String query = `` SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB` WHERE `CITY` = ‘INDIANAPOLIS' ORDER BY `EMP_ID`, `LAST_NAME`; ``;
下面是几个 JEP 326 中提到的问题
多行字符串时边界的管理
如果对上面的 json
变量输出的控制台，将会是下面的样子 (点号代表空格)
{ ................."id": 1234 ................."name": "Yanbin" .................}
如果需要我们期望的漂亮格式，代码声明就得改成
String json = `{
"id": 123,
"name": "Yanbin"
}`;
也不赖，边界的管理也就发生在第一行和最末一行。该 JEP 326 中未描述边界如何控制，可看看 Scala 的做法
val json = """|{
| "id": 123,
| "name": "Yanbin"
|}""".stripMargin
有了那道杠杠，总能把格式控制的漂漂亮亮。
边界符的选择
JEP 326 中用的是一个或两个斜撇号，正式加入该特性后，都说不定。边界符的选择需避免二义性，又要在实际字符串中出现频度尽可能少的，可借鉴比较通行的用法，如
"""..."""
： Groovy, Kotlin, Python, Scala, Swift
...
@"..."
： C#
R"..."
： Groovy (old style)
R"xxx(...)xxx"
： C/C++
%(...)
： Ruby
qq{...}
： Perl
关于字符串插值(interpolation)
该 JEP 并不打算实现这一功能，或许在将来。因此基本第一个版本别希望下如下字符串中的变量引用与方法调会被解析
Hello $name, number: ${count.get()}`
Heredoc 的支持
Here document 是 Linux Shell 和 Perl 爱用的多行字符串表示法，以任意配对的首尾标记来框住多行字符串，例如:
System.out.println(<<HTML); <html> <body> <p>Hello World.</p> </body> </html> HTML
由于该 JEP 仍处在候选状态，开发过程中，所以下载不到一个含该特性的 JDK 11 进行抢先体验，最终 JDK 11 的发布将在九月份，不知三个月后能否事与愿为。
正文到此结束
热门推荐
相关文章
近期评论
-
你这基本没有更新呀，最近文章显示还是2019年的文章。不符合要求哈
-
关键词：慕云博客 链接：https://www.lilun.me 描述：分享原创文字的个人博客
-
-
-
可以提供一下源码吗
-
不是商业站，鸡娃学习笔记
-
-
-
-
听他们说很厉害的样子
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
