隔叶黄莺 Yanbin Blog

Java 六个月的版本迭代周期让我们突然间有些喘不过气来，又 Java 11 才会是一个长期支持版本，如果可能的话我们将会是从 Java 8 直接往 Java 11 跳去。在 Java 8 大行其道，裹足不前的当下，谈论着未来 Java 11 不确定的新特性，有一种看着别人家碗里的不过瘾，还要看着别人家锅里的感觉。

本篇原本只是为了对 Java 11 潜在的原始字符串字面量(Raw String Literals)的哨探，同时考虑到 Java 10 仅有的一个语言层面的新特性 var 局部变量类型推断，所以顺带介绍一下。

我这儿把它称之为 var 局部变量类型推断，说明了var 类型推断并不适用于类或实例的变量，或方法的参数。而且 var 也并未上升为一个  Java 的关键字，我们仍然可以用 var 作为变量或方法名。

对局部变量用 var 进行类型推断的代码示例变化如下：

var 学了 Scala 的语法，再重复一遍，var 只能用于局部变量，这有一个好处就是局部变量的跨越性较小，不至于 var 声明的变量阅读时只有编译器知道它的确切类型。var 类型推断给代码书写上的变化就是对局部变量的任何类型声明都可以替代为 var。 阅读全文 >>

平台之所以谓之平台，以其能建立一个生态，并与之外围达成共赢。霸道点的平台也会反噬外围生态，像微软集成浏览器，媒体播放器。还有即将的 iOS 12 要把应用商店多是收费的 AR 皮尺放到它自己系统中来，走别人的路，让别人无路可走。从此众泰皮尺部的唯一的生产工具就会是人手一部能安装 iOS 12 iPhone 了。

JDK 也不例外，Java 8 之前日期库的话 Joda-Time 是首要之选，Java 8 集成后应该是鲜有人问津。以往说到集合操作库，有两个选择，其一为 Apache Commons Collections，二为 Google 的 Guava，当然前者与后者竞争中也早已败下阵来，况且前者还受到 Java 8 的夹击。而本文要说的可以说是 Java 9 把 Guava 中创建不可变集合的方式据为已用了，直截了当的说，凡是 Java 9 后有创建不可变集合的需求，只要用三大接口 List， Set，Map 中的 of(...) 方法就对了。

Java 9 之前，当我们需要集合相关的操作，两个选择：

1. Apache Commons Collections 的几个类 ListUtils, SetUtils, MapUtils, 和 CollectionsUtils。比如它们提供的以下几些个工具方法
   

   ListUtils.unmodifiableList<List<? extends E> list)   //创建不可变 List
   SetUtils.emptySet()  //不可变的空  Set
   SetUtils.unmodifiableSet(Set<? extends E> set)  //创建不可变 Set
   MapUtils.unmodifiableMap(Map<? extends K, ? extends V> map)  //创建不可变 Map
   CollectionUtils.unmodifiableCollection(Collection<? extends C> collection)  //创建不可变集合

2. Guava 的几个类 ImmutableList, ImmutableSet, 和 ImmutableMap。而它们创建不可变集合的方式就是通过各自的 of(...) 方法，以 ImmutableList 为例(其余两个类也类似)，它有
   

   of(): ImmutableList<E>
   of(E element): ImmutableList<E>
   of(E e1, E e2): ImmutableList<E>
   of(E e1, E e2, E e3): ImmutableList<E>
   ......
   of(E e1, E e2, E e3, E e4, E e5, E e6, E e7, E e8, E e9, E e10, E e11, E e12, E... others): ImmutableList<E>

阅读全文 >>

什么是线程栈

继续纠缠 Java 9 的新特性，仍然是一个边角料，即 Java 9 增加了对线程栈遍历的 API。那么什么是线程栈，JVM 在创建每一个线程的同时都会创建一个私有的虚拟机栈，每一桢代表着一个方法调用，每次方法的调用与退出意味着压栈与出栈。每一桢上有局部变量，操作数常量引用等信息，这也是为什么局部变量是能最快被销毁的对象。过深的栈(比如过多的递归调用) 会出现我们程序员赖以生存的 StackOverflow。

浅显些说，线程栈就是通常我们捕获到异常后，用 e.printStackTrace() 看到自 main 方法追溯到当前方法的调用。例如：

java.lang.RuntimeException: stack
    at cc.unmi.TestStackWalking.m2(TestStackWalking.java:15)
    at cc.unmi.TestStackWalking.m1(TestStackWalking.java:10)
    at cc.unmi.TestStackWalking.main(TestStackWalking.java:6)

调用层次是 main() 调用 m1(), m1() 调用 m2(), m2() 中的代码如下

上面输出的每一行就是一个栈桢，输出了当前类名，方法名，代码行号。 阅读全文 >>

我们知道 Java 的合法命名是以字母或下划线开头的字符串，当然，以前单个下划线 _ 也是一个合法的变量命名。但是自 Java 8 的第一个版本开始，单个下划线的变量名编译时会有警告

int _ = 99;

用 Java 8 编译时提示警告：

Test.java:2: warning: '_' used as an identifier
    int _ = 99;
         ^
    (use of '_' as an identifier might not be supported in releases after Java SE 8)
1 warning

这正是为 Java 9 作的预谋，以一个 LTS 版的 Java 8 作为过渡。因此，来到了 Java 9 后，单个下划线不再担当普通变量名的角色，变成了一个保留关键字，只说是另有任用。

先来看下 Java 9 中的单个下划线变量名编译时的错误提示

Test.java:2: error: as of release 9, '_' is a keyword, and may not be used as an identifier
    int _ = 99;
         ^
1 error

到底单下划线会作为什么用途呢? 已发布的 Java 10 没有给出答案，正在演进中的 Java 11 也没有相关的信息。 阅读全文 >>

关于 Java 9 的新特性从某本书的最后一个说起：平台日志 API。个人没感觉这个有什么实质的用途，所谓的平台日志是指 JDK 自身代码，或者是 JVM 组件中的日志输出，而在自己应用程序代码中却不会去用这个平台日志 API。这个所谓的 Platform Logging API 名称的意义也就是在这里，平台用的，在诊断时用来观察 JDK 类或 JVM 中的日志输出，比如应该可以截获到  JVM 本地代码实现中的日志输出。对我们在项目中如何处理日志并不会有什么影响，该怎么还是怎么，不过了解多一点东西应该不会浪费脑容量的。

新加的平台日志体现在 java.lang.System 中新加的几个方法和类

我们可以尝试着在代码使用一下它

输出如下

May 26, 2018 10:56:51 AM cc.unmi.TestLogging main
INFO: Hello Java 9 Platform Logging API

阅读全文 >>