JDK 14 新特性,参考openjdk14
1. JEP 305 instanceof 模式匹配(预览)
一个简单的例子,原来的写法:
if (obj instanceof String) {
String s = (String) obj;
// use s
}
现在的写法:
if (obj instanceof String s) {
// can use s here
} else {
// can't use s here
}
2. JEP 343 PackaingTool(Incubator), 打包工具(培养), 也就是说将Java打包都平台上可直接运行,比如msi,exe,rpm, deb,pkg等
基本用法:非模块化应用
假设您有一个包含JAR文件的应用程序,所有应用程序都位于一个名为的目录中lib,并且lib/main.jar包含主类。然后命令
$ jpackage --name myapp --input lib --main-jar main.jar
将以本地系统的默认格式打包应用程序,将生成的打包文件保留在当前目录中。如果其中的MANIFEST.MF文件main.jar没有Main-Class属性,则必须显式指定主类:
$ jpackage --name myapp --input lib --main-jar main.jar
–main-class myapp.Main
软件包的名称将为myapp,尽管软件包文件本身的名称将更长,并以软件包类型(例如myapp.exe)结尾。该软件包将包括该应用程序的启动器,也称为myapp。要启动该应用程序,启动程序会将从输入目录复制的每个JAR文件放在JVM的类路径上。
如果您希望以默认格式以外的格式生成软件包,请使用该–type选项。例如,要在macOS上生成pkg文件而不是dmg文件:
$ jpackage --name myapp --input lib --main-jar main.jar --type pkg
基本用法:模块化应用
如果您有一个模块化应用程序,该应用程序由目录中的模块化JAR文件和/或JMOD文件组成,并且模块中lib包含主类myapp,则命令
$ jpackage --name myapp --module-path lib -m myapp
将其打包。如果myapp模块未标识其主类,则必须再次明确指定:
$ jpackage --name myapp --module-path lib -m myapp/myapp.Main
(打包模块化JAR或JMOD文件时,可以使用和工具–main-class选项指定主类。)jarjmod
包元数据
该jpackage工具允许您为程序包指定各种元数据。所有平台共有的选项是:
–app-version
–copyright
–description
–license-file
–name
–vendor
该工具以适合软件包类型的方式使用提供给这些选项的参数。特定于平台的软件包元数据选项如下所述。
3. JEP 345 针对G1的NUMA感知内存分配
4. JEP 349 JFR event Streaming
关于jvm 分析用的;
5. JEP 352: Non-Volatile Mapped Byte Buffers 非易失性映射字节缓冲区
jvm 对 非易失性存储器的访问(NVM)
6. JEP 358: 有用的NullPointerExceptions
NullPointerExceptions 异常信息中包含抛出异常的哪个字段,
以前是仅仅抛出行号;
7. JEP 359: Records (Preview) 记录(预览)
数据载体,DTO,中只有字段,自动生成getter, setter, toString 和Equals
record Point(int x, int y) { }
8. JEP 361: Switch Expressions (Standard) 开关表达式(标准)
switch(day){
无返回值
switch (day) {
case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
case TUESDAY -> System.out.println(7);
case THURSDAY, SATURDAY -> System.out.println(8);
case WEDNESDAY -> System.out.println(9);
}
有返回值
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
case THURSDAY, SATURDAY -> 8;
case WEDNESDAY -> 9;
};
如果是多行,通过 yield 返回
int result = switch (s) {
case "Foo":
yield 1;
case "Bar":
yield 2;
default:
System.out.println("Neither Foo nor Bar, hmmm...");
yield 0;
};
// 穷举
int i = switch (day) {
case MONDAY -> {
System.out.println("Monday");
// ERROR! Block doesn't contain a yield statement
}
default -> 1;
};
i = switch (day) {
case MONDAY, TUESDAY, WEDNESDAY:
yield 0;
default:
System.out.println("Second half of the week");
// ERROR! Group doesn't contain a yield statement
};
9. JEP 362: Deprecate the Solaris and SPARC Ports,弃用Solaris和SPARC端口
不在支持Solaris 和 SPARC
10. JEP 363: 删除并发标记扫描(CMS)垃圾收集器
11. JEP 364: Mac OS上的ZGC (实验性)
12. JEP 365: Windows上的ZGC(实验性)
13. JEP 366: 弃用ParallelScavenge + SerialOld GC组合
14. JEP 367: 删除Pack200工具和API
删除jar 文件Pack200压缩方案工具
15.JEP 368: 文本块(第二预览)
三个双引号
"""
function hello() {
print('"Hello, world"');
}
hello();
"""
16. JEP 370: 外部存储器访问API(孵化器)
直接访问内存;
开发原因:
许多现有的Java库和程序都访问外部存储器,例如Ignite,mapDB,memcached和Netty的ByteBuf API。这样,他们可以
避免与垃圾回收相关的成本和不可预测性(尤其是在维护大型缓存时),
跨多个进程共享内存,并且
通过将文件映射到内存(例如通过mmap)来序列化和反序列化内存内容。
但是,Java API不能提供令人满意的访问外部内存的解决方案。