java15新功能的详细讲解

• 1. jep 339 爱德华曲线算法（eddsa）
• 2. jep 360：sealed classes（密封类）预览
• 3. jep 371：hidden classes（隐藏类）
• 4. jep 372：移除 nashorn javascript 引擎
• 5. jep 373：重新实现 datagramsocket api
• 6. jep 374：禁用和废弃偏向锁（biased locking）
• 7. jep 375：instanceof 类型匹配 (二次预览)
• 8. jep 377：zgc: 可扩展低延迟垃圾收集器（正式发布）
• 9. jep 378： 文本块
• 10. jep 379：shenandoah: 低停顿时间的垃圾收集器
• 11. jep 384：records（二次预览）

java 15 在 2020 年 9 月发布，虽然不是长久支持版本，但是也带来了 14 个新功能，这些新功能中有不少是十分实用的。

java 15 官方下载：

java 15 官方文档：

java 15 新功能：

jep	描述
jep 339	爱德华曲线算法（eddsa）
jep 360	sealed classes（密封类）预览
jep 371	hidden classes（隐藏类）
jep 372	移除 nashorn javascript 引擎
jep 373	重新实现 datagramsocket apii
jep 374	禁用和废弃偏向锁（biased locking）
jep 375
jep 377	zgc: 可扩展低延迟垃圾收集器（正式发布）
jep 378
jep 379	shenandoah: 低停顿时间的垃圾收集器
jep 381	删除 solaris 和 sparc 端口
jep 383	外部内存访问 api（第二个孵化器）)
jep 384	records (二次预览)
jep 385	废弃 rmi 激活机制

1. jep 339 爱德华曲线算法（eddsa）

java 15 中增加了一个新的密码学算法，爱德华曲线算法（eddsa）签名算法。它是由 schnorr 算法发展而来，在 rfc8032 中被定义实现。

package com.wdbyte;

import java.nio.charset.standardcharsets;
import java.security.invalidkeyexception;
import java.security.keypair;
import java.security.keypairgenerator;
import java.security.nosuchalgorithmexception;
import java.security.signature;
import java.security.signatureexception;
import java.util.base64;

public class jep339 {

    public static void main(string[] args) throws nosuchalgorithmexception, invalidkeyexception, signatureexception {
        keypairgenerator kpg = keypairgenerator.getinstance("ed25519");
        keypair kp = kpg.generatekeypair();
        byte[] msg = "www.wdbyte.com".getbytes(standardcharsets.utf_8);
        signature sig = signature.getinstance("ed25519");
        sig.initsign(kp.getprivate());
        sig.update(msg);
        byte[] s = sig.sign();
        system.out.println(base64.getencoder().encodetostring(s));
    }
}

输出结果：

vxlpxapu+lswjvq0qnjvdpuh6vi6pjswoq2phu65bcfnlr13oywkunlc9rc+7smxch2mnqf7tmc/iog8oimbaw==

2. jep 360：sealed classes（密封类）预览

我们都知道，在 java 中如果想让一个类不能被继承和修改，这时我们应该使用 final 关键字对类进行修饰。不过这种要么可以继承，要么不能继承的机制不够灵活，有些时候我们可能想让某个类可以被某些类型继承，但是又不能随意继承，是做不到的。java 15 尝试解决这个问题，引入了 sealed 类，被 sealed 修饰的类可以指定子类。这样这个类就只能被指定的类继承。

而且 sealed 修饰的类的机制具有传递性，它的子类必须使用指定的关键字进行修饰，且只能是 final 、sealed 、non-sealed 三者之一。

示例：犬类（dog）只能被牧羊犬（collie）和田园犬（tugou）继承，使用 sealed 关键字。

package com.wdbyte;

public  sealed interface dog permits collie, tugou {
    //...
}

牧羊犬（collie）只能被边境牧羊犬（bordercollie）继承。

package com.wdbyte;

/**
 * 牧羊犬
 * @author www.wdbyte.com
 */
public sealed class collie implements dog permits bordercollie {

}

边境牧羊犬（bordercollie）不能被继承，使用 final 关键字。

package com.wdbyte;

/**
 *
 * @author www.wdbyte.com
 */
public final class bordercollie extends collie{
}

田园犬（togou）可以被任意继承，使用 non-sealed 关键字。

package com.wdbyte;

/**
 * @author niulang
 */
public non-sealed class tugou implements dog {
}

3. jep 371：hidden classes（隐藏类）

这个特性让开发者可以引入一个无法被其他地方发现使用，且类的生命周期有限的类。这对运行时动态生成类的使用方式十分有利，可以减少内存占用，下面是一个使用示例。

package com.wdbyte;

public class jep371test {
    public static string lookup() {
      return "www.wdbyte.com";
    }
}

把类 jep371test 编译后的 class 转换成 base64，然后使用 java 15 新特性加载调用类中的 lookup 方法。

package com.wdbyte;

import java.lang.invoke.methodhandle;
import java.lang.invoke.methodhandles;
import java.lang.invoke.methodtype;
import java.util.base64;

/**
 * @author www.wdbyte.com
 */
public class jep371 {

    private static string class_info = "yv66vgaaadqafaoaagadbwaedaafaaybabbqyxzhl2xhbmcvt2jqzwn0aqagpgluaxq+aqadkclwcaaiaqaod3d3lndkynl0zs5jb20haaobabvjb20vd2riexrll0pfudm3mvrlc3qbaardb2rlaqaptgluzu51bwjlclrhymxlaqastg9jywxwyxjpywjszvrhymxlaqaedghpcweaf0xjb20vd2riexrll0pfudm3mvrlc3q7aqagbg9va3vwaqaukclmamf2ys9syw5nl1n0cmluzzsbaaptb3vyy2vgawxlaqapskvqmzcxvgvzdc5qyxzhaceacqacaaaaaaacaaeabqagaaeacwaaac8aaqabaaaabsq3aagxaaaaagamaaaabgabaaaaawanaaaadaabaaaabqaoaa8aaaajabaaeqabaasaaaabaaeaaaaaaamsb7aaaaabaawaaaagaaeaaaaeaaeaegaaaaiaew==";

    public static void main(string[] args) throws throwable {
        byte[] classinbytes = base64.getdecoder().decode(class_info);
        class<?> proxy = methodhandles.lookup()
            .definehiddenclass(classinbytes, true, methodhandles.lookup.classoption.nestmate)
            .lookupclass();

        system.out.println(proxy.getname());
        methodhandle mh = methodhandles.lookup().findstatic(proxy, "lookup", methodtype.methodtype(string.class));
        string result = (string) mh.invokeexact();
        system.out.println(result);
    }
}

输出结果：

com.wdbyte.jep371test/0x0000000800c01800
www.wdbyte.com

4. jep 372：移除 nashorn javascript 引擎

nashorn javascript 引擎在 java 8 中被引入，在 java 11 中被标记为废弃。由于 ecmascript 语言发展很快，维护 nashorn javascript 的成本过于高昂，在 java 15 中被彻底删除。

扩展阅读：nashorn javascript engine，deprecate the nashorn javascript engine

5. jep 373：重新实现 datagramsocket api

java 13 中重新实现了旧的 socket api，在介绍 java 13 时还有一部分做了这方面的介绍。

现在，java 15 重新实现了遗留的 datagramsocket。

扩展阅读：java 13 新功能介绍

6. jep 374：禁用和废弃偏向锁（biased locking）

在之前，jvm 在处理同步操作，如使用 synchronized 同步时，有一套锁的升级机制，其中有一个锁机制就是偏向锁。然而通过目前的 java 开发环境来看，使用这些被 synchronized 同步的类的机会并不多，如开发者更喜欢使用 hashmap 或者 arraylist 而非 hashtable 和 vector。

即使换个角度，当初使用偏向锁是为了提高性能，如今看来性能提升的程度和使用次数都不太有用。而偏向锁的引入增加了 jvm 的复杂性。

所以现在偏向锁被默认禁用，在不久的将来将会彻底删除，对于 java 15，我们仍然可以使用-xx:+usebiasedlocking 启用偏向锁定，但它会提示 这是一个已弃用的 api。

7. jep 375：instanceof 类型匹配 (二次预览)

instanceof 类型匹配在 java 14 中已经改进，这次仅仅再次预览，没有任何改动，用于接受更多的使用反馈。这个特性在 java 16 中成为正式特性。

在之前，使用 instanceof 进行类型判断之后，需要进行对象类型转换后才能使用。

package com.wdbyte;

import java.util.arraylist;
import java.util.list;

public class java14beaforinstanceof {

    public static void main(string[] args) {
        object obj = new arraylist<>();
        if (obj instanceof arraylist) {
            arraylist list = (arraylist)obj;
            list.add("www.wdbyte.com");
        }
        system.out.println(obj);
    }
}

而在 java 14 中，可以在判断类型时指定变量名称进行类型转换，方便了使用。

package com.wdbyte;

import java.util.arraylist;

public class java14instanceof {
    public static void main(string[] args) {
        object obj = new arraylist<>();
        if (obj instanceof arraylist list) {
            list.add("www.wdbyte.com");
        }
        system.out.println(obj);
    }
}

可以看到，在使用 instanceof 判断类型成立后，会自动强制转换类型为指定类型。

输出结果：

[www.wdbyte.com]

扩展阅读：java 14 新功能介绍

8. jep 377：zgc: 可扩展低延迟垃圾收集器（正式发布）

zgc 垃圾收集器在 java 11 中被引入，但是因为收集器的复杂性，当初决定逐渐引入。然后不断的听取用户的反馈建议修复问题。而现在，已经很久没有收到用户的问题反馈了，zgc 是时候投入正式使用阶段了。所以在 java 15 中 zgc 正式发布，可以使用下面的参数启用 zgc。

$ java -xx:+usezgc classname

9. jep 378： 文本块

文本块在 java 12 jep 326 原始字符串文字 中引入，在 java 13 jep 355：文本块（预览） 中开始预览，在 java 14 jep 368：文本块（第二次预览），而现在，在 java 15 ，文本块是正式的功能特性了。

string content = """
        {
            "uppersummary": null,\
            "sensitivetypelist": null,
            "gmtmodified": "2011-08-05\s10:50:09",
        }
         """;
system.out.println(content);

扩展阅读：java 14 新功能介绍- jep368 文本块

10. jep 379：shenandoah: 低停顿时间的垃圾收集器

shenandoah 垃圾收集器在 java 12 中开始引入，java 15 中成为了正式功能的一部分，可以使用下面的参数启用 shenandoah 垃圾收集器。

java -xx:+useshenandoahgc

但是 openjdk 15 中默认是没有 shenandoah 收集器，想要使用此功能可以下载 adoptopenjdk。

为什么 openjdk 中没有 shenandoah 垃圾收集器？

shenandoah 是一个高性能、低暂停时间的垃圾收集器，它是 red hat 主导的项目。当 red hat 第一次提议将 shenandoah 贡献给 openjdk 时，oracle 明确表示不想支持它，openjdk 作为一个免费软件，不想支持 red hat 的 shenandoah 完全没有问题。

最后 red hat 选择和 oracle 合作设计一个真正干净的可插拔垃圾收集器接口，允许任何人轻松选择垃圾收集器以包含在他们的构建中。最终 shenandoah 进入了 jdk 12，但是没有构建进 openjdk。

11. jep 384：records（二次预览）

在 java 14 中引入了 record 类，java 15 中对 record 进行了增强。使它可以支持密封类型、record 注解以及相关的反射 api 等。

示例：record 支持密封（sealed）类型。

package com.wdbyte;

/**
 * @author www.wdbyte.com
 */
public sealed interface database permits databaseselect, databaseupdate {
}

final record databaseselect(@deprecated string table, string sql) implements database {
}

final record databaseupdate() implements database {
}

在 java.lang.class 增加了两个公共方法用于获取 record 类信息：

1. recordcomponent[] getrecordcomponents()
2. boolean isrecord()

其他更新

jep 381：删除 solaris 和 sparc 端口

java 14 jep 362弃用了 solaris/sparc、solaris/x64 和 linux/sparc 端口，现在它在 java 15 中被正式删除。

jep 383：外部内存访问 api（第二个孵化器）

jep 385：废弃 rmi 激活机制

只是废弃 rmi 激活机制，不影响 rmi 其他功能。

参考

到此这篇关于java15新功能的详细讲解的文章就介绍到这了,更多相关java15新功能介绍内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！