JDK15
JEP 339：EdDSA 数字签名算法
Edwards-Curve Digital Signature Algorithm (EdDSA)实现
Example API usage:
// example: generate a key pair and sign
KeyPairGenerator kpg = KeyPairGenerator.getInstance("Ed25519");
KeyPair kp = kpg.generateKeyPair();
// algorithm is pure Ed25519
Signature sig = Signature.getInstance("Ed25519");
sig.initSign(kp.getPrivate());
sig.update(msg);
byte[] s = sig.sign();
// example: use KeyFactory to contruct a public key
KeyFactory kf = KeyFactory.getInstance("EdDSA");
boolean xOdd = ...
BigInteger y = ...
NamedParameterSpec paramSpec = new NamedParameterSpec("Ed25519");
EdECPublicKeySpec pubSpec = new EdECPublicKeySpec(paramSpec, new EdPoint(xOdd, y));
PublicKey pubKey = kf.generatePublic(pubSpec);
JEP 360：密封类（预览）
目标
- 允许类或接口的作者控制哪个代码负责实现它。
- 提供比访问修饰符更具声明性的方式来限制超类的使用。
- 通过支持对模式的详尽分析，支持模式匹配的未来方向。
在Java中，类层次结构允许通过继承重用代码：超类的方法可以被许多子类继承（从而重用）。但是，类层次结构的目的并不总是重用代码。有时，其目的是对域中存在的各种可能性进行建模，例如图形库支持的形状类型或金融应用程序支持的借阅类型。以这种方式使用类层次结构时，限制子类集可以简化建模。
例如，在图形库中，类的作者可能希望只有特定的类可以扩展，因为库的大部分工作都涉及以适当的方式处理每种形状。作者对 处理 的已知子类的代码的清晰度感兴趣，并且对编写代码来防御 的未知子类不感兴趣。在这种情况下，允许任意类扩展，从而继承其代码以供重用，这不是一个目标。不幸的是，Java假设代码重用始终是一个目标：如果可以扩展，那么它可以通过任意数量的类进行扩展。放宽此假设会很有帮助，这样作者就可以声明一个不为任意类扩展而开放的类层次结构。在这样一个封闭的类层次结构中，代码重用仍然是可能的，但不能超越。
package com.example.geometry;
public abstract sealed class Shape
permits Circle, Rectangle, Square {...}
上面的例子中，我们指定了Shape只允许被Circle, Rectangle, Square来继承。
上面的例子中并没有指定类的包名，我们可以这样写：
package com.example.geometry;
public abstract sealed class Shape
permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square
{...}
package com.example.geometry;
public abstract sealed class Shape
permits Circle, Rectangle, Square {...}
public final class Circle extends Shape {...}
public sealed class Rectangle extends Shape
permits TransparentRectangle, FilledRectangle {...}
public final class TransparentRectangle extends Rectangle {...}
public final class FilledRectangle extends Rectangle {...}
public non-sealed class Square extends Shape {...}
这里使用了3个关键字，一个是sealed，一个是permits，一个是non-sealed；permits的这些子类要么使用final，要么使用sealed，要么使用non-sealed修饰；针对record类型，也可以使用sealed，因为record类型暗示这final
package com.example.expression;
public sealed interface Expr
permits ConstantExpr, PlusExpr, TimesExpr, NegExpr {...}
public record ConstantExpr(int i) implements Expr {...}
public record PlusExpr(Expr a, Expr b) implements Expr {...}
public record TimesExpr(Expr a, Expr b) implements Expr {...}
public record NegExpr(Expr e) implements Expr {...}
JEP 371：隐藏类
引入隐藏类，这些类不能被其他类的字节码直接使用。隐藏类旨在供在运行时生成类并通过反射间接使用它们的框架使用。隐藏类可以被定义为访问控制嵌套的成员，并且可以独立于其他类被卸载。为frameworks提供在运行时生成内部的class
如果标准 API 可以定义不可发现且生命周期有限的隐藏类，那么动态生成类的 JDK 内部和外部的框架可以改为定义隐藏类。这将提高在JVM上构建的所有语言实现的效率。例如：
java.lang.reflect.Proxy可以定义隐藏类来充当实现代理接口的代理类;java.lang.invoke.StringConcatFactory可以生成隐藏类来保存常量串联方法;java.lang.invoke.LambdaMetaFactory可以生成隐藏的嵌套类来保存访问封闭变量的 lambda 主体;和- JavaScript 引擎可以为从 JavaScript 程序翻译的字节码生成隐藏类，因为当引擎不再使用它们时，这些类将被卸载。
JEP 372：移除 Nashorn JavaScript 引擎
具体就是jdk.scripting.nashorn及jdk.scripting.nashorn.shell这两个模块被移除了
JEP 373：重新实现 Legacy DatagramSocket API
将 java.net.DatagramSocket及java.net.MulticastSocket API 的基础实现替换为更简单、更现代、更易于维护和调试的实现。新的实现将很容易适应与虚拟线程一起工作，目前正在Project Loom中探索。这是JEP 353的后续版本，JEP 353已经重新实现了传统的套接字API。
JEP 374：禁用偏向锁定
在 JDK 15 之前，偏置锁定始终处于启用状态且可用。使用此 JEP，除非在命令行上设置了热点，否则在启动 HotSpot 时将不再启用偏倚锁定。-XX:+UseBiasedLocking
我们将弃用该选项以及与配置和使用偏置锁定相关的所有选项。-XX:+UseBiasedLocking
- Product options:
BiasedLockingStartupDelay,BiasedLockingBulkRebiasThreshold,BiasedLockingBulkRevokeThreshold,BiasedLockingDecayTimeandUseOptoBiasInlining - Diagnostic options:
PrintBiasedLockingStatisticsandPrintPreciseBiasedLockingStatistics
JEP 375：instanceof 模式匹配（第二次预览）
instanceof的Pattern Matching在JDK15进行Second Preview
@Override
public boolean equals(Object o) {
return (o instanceof CaseInsensitiveString) &&
((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
}
@Override
public boolean equals(Object o) {
return (o instanceof CaseInsensitiveString cis) &&
cis.s.equalsIgnoreCase(s);
}
JEP 377：ZGC：一个可扩展的低延迟垃圾收集器
ZGC在JDK11被作为experimental feature引入，在JDK15变成Production，但是这并不是替换默认的GC，默认的GC仍然还是G1；
ZGC是一个重新设计的并发的垃圾回收器，可以极大的提升GC的性能。支持任意堆大小而保持稳定的低延迟（10ms以内），性能非常可观。
打开方式：使用-XX:+UseZGC命令行参数打开;
JEP 378：文本块
Text Blocks首次是在JDK 13中以预览功能出现的，然后在JDK 14中又预览了一次，在JDK15转正
JEP 379：Shenandoah:低暂停时间垃圾收集器
Shenandoah在JDK12被作为experimental引入，在JDK15变为Production；之前需要通过-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC来启用，现在只需要-XX:+UseShenandoahGC即可启用
henandoah和ZGC的异同点大：
- 相同点：性能几乎可认为是相同的
- 不同点：ZGC是Oracle JDK的，根正苗红。而Shenandoah只存在于OpenJDK中，因此使用时需注意你的JDK版本
JEP 381：移除 Solaris 和 SPARC 端口
如题
JEP 383：外部存储器访问 API（第二次孵化版）
Foreign-Memory Access API在JDK14被作为incubating API引入，在JDK15处于Second Incubator，提供了改进。
JEP 384：Records（第二次预览）
Records在JDK14被作为preview引入，在JDK15处于Second Preview
JEP 385：废弃 RMI 激活机制
对于现代应用程序来说，分布式系统大部分都是基于Web的，web服务器已经解决了穿越防火墙，过滤请求，身份验证和安全性的问题，并且也提供了很多延迟加载的技术。所以在现代应用程序中，RMI Activation已经很少被使用到了。并且在各种开源的代码库中，也基本上找不到RMI Activation的使用代码了。为了减少RMI Activation的维护成本，在JDK8中，RMI Activation被置为可选的。现在在JDK15中，终于可以废弃了。
参考资料
JDK 15 Release Notes, Important Changes, and Information (oracle.com)
博客
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
