Inside Java Newscast #1 深度解讀

本文是 Inside Java Newscast #1 的個人體驗與解讀。視訊地址：點選這裡

⎯⎯⎯⎯⎯⎯ Chapters ⎯⎯⎯⎯⎯⎯

• 0:00 - Intro
• 0:57 - Java 16 – Intro
• 1:16 - Java 16 – Records
• 1:43 - Java 16 – Type Pattern Matching
• 1:58 - Java 16 – Sealed Classes - Preview
• 2:25 - Java 16 – Stream API
• 2:51 - Java 16 – HTTP/2 API
• 3:14 - Java 16 – Unix Domain Sockets
• 3:32 - Java 16 – Project Panama (Incubating)
• 4:07 - Java 16 – JDK Flight Recorder
• 4:39 - Java 16 – jpackage
• 5:02 - Java 16 – Performance
• 5:23 - Java 16 – Security
• 5:48 - Java 16 – Ports
• 5:55 - Java 16 – Deprecations/Limitations
• 6:49 - Java 16 – Outro
• 7:08 - Java 17
• 7:22 - Java 17 – Another Port
• 7:34 - Java 17 – Applet for Removal
• 7:55 - Java 17 – Sealed Classes
• 8:12 - Outro

Java 16 – Records

相關 JEP 地址：

• JEP 359: Records(Preview)
• JEP 384: Records (Second Preview)
• JEP 395: Records

Records 這個特性我仔細研究過實現：參考我寫的另一篇文章Java Record 的一些思考 - 預設方法使用以及基於預編譯生成相關位元組碼的底層實

簡單說來其實就是（編譯後檢視下位元組碼就能看出來），在編譯後，根據 Record 原始碼插入相關域與方法的位元組碼，包括：

1. 自動生成的 private final field
2. 自動生成的全屬性構造器
3. 自動生成的 public getter 方法
4. 自動生成的 hashCode()，equals()，toString() 方法：
5. 從位元組碼可以看出，這三個方法的底層實現是 invokeDynamic 另一個方法
6. 呼叫的是 ObjectMethods.java 這個類中的 bootstrap 方法

這個還讓我鬧了個笑話，我以為這個是 Project Valhala 的 Inline Object 已經實現了（參考我的這個系列： JEP 嚐鮮系列），還去 StackOverflow 問，這個 Record 為啥能有 wait() 方法，並且可以進行 synchronized 同步（因為如果是 Project Valhala 的 Inline Object 的話是沒有普通類的物件頭的，沒法用普通類物件的方法實現同步），結果。。。。。最後還是 Goetz 大佬一眼就看出我是誤會了：

Record 這個特性當初是為了適應什麼場景設計的，以及某些設計為何被捨棄，可以參考 Gotez 大佬的這篇文章 java-14-feature-spotlight. 其重中主要的看點總結如下：

1.Java Records 最常用於的地方就是方法多個返回結果，原來我們可能需要用 Apache-commons 裡面的 Pair 或者 Tuple 這樣的物件封裝，或者自己新建一個型別。現在可以使用 Record。

2.第二個常見應用即在 Stream 中傳遞的過程中保持原有物件，並且減少運算，例如 Stream 排序：

List<Player> topN
        = players.stream()
             .sorted(Comparator.comparingInt(p -> getScore(p)))
             .limit(N)
             .collect(toList());

這麼寫的話，每次作比較都會呼叫一次 getScore(p)，這個呼叫次數是 O(n^2)。利用 Record 可以用比較少的程式碼和改動實現減少運算：

record PlayerScore(Player player, Score score) {
    // convenience constructor for use by Stream::map
    PlayerScore(Player player) { this(player, getScore(player)); }
}

List<Player> topN
    = players.stream()
             .map(PlayerScore::new)
             .sorted(Comparator.comparingInt(PlayerScore::score))
             .limit(N)
             .map(PlayerScore::player)
             .collect(toList());

最後再推薦下我寫的這篇關於 Record 的序列化的一些解析和思考：Java Record 的一些思考 - 序列化相關

Java 16 – Type Pattern Matching

相關 JEP 地址：

• JEP 305: Pattern Matching for instanceof (Preview)
• JEP 375: Pattern Matching for instanceof (Second Preview)
• JEP 394: Pattern Matching for instanceof

型別模式匹配一直是一個呼聲很高的特性，如果和下一小節的 Sealed Class 特性 以及 Patterns in switch 結合起來使用會有更好的效果，這個我們在下一節會更詳細的說明.

Nicolai 對 Type Pattern Matching 的說明

Nicolai 的這篇文章 對 Type Pattern Matching 的說明非常詳細，總結如下：

原來需要這麼寫的程式碼：

void feed(Animal animal) {
    if (animal instanceof Elephant) {
	    ((Elephant) animal).eatPlants();
    }
    else if (animal instanceof Tiger) {
	    ((Tiger) animal).eatMeat();
	}
	
}

現在可以直接這麼寫：

void feed(Animal animal) {
	if (animal instanceof Elephant elephant)
		elephant.eatPlants();
	else if (animal instanceof Tiger tiger)
		tiger.eatMeat();
}

不需要空指標判斷，因為 instanceof 已經自帶 null 判斷了，符合條件的 Type Pattern Matching 變數不會為 null。並且， Type Pattern Matching 不支援向上匹配，因為這個沒有意義，即下面的程式碼會編譯報錯：

public void upcast(String string) {
	// compile error
	if (string instanceof CharSequence sequence)
		System.out.println("Duh");
}

還有一個常用的地方即實現 equals：

// old
@Override
public boolean equals(Object o) {
	if (this == o)
		return true;
	if (!(o instanceof Equals))
		return false;
	Type other = (Type) o;
	return someField.equals(other.someField)
		&& anotherField.equals(other.anotherField);
}

// new
@Override
public final boolean equals(Object o) {
	return o instanceof Type other
		&& someField.equals(other.someField)
		&& anotherField.equals(other.anotherField);
}

其實 Type Pattern Matching 是個語法糖

其實這個特性是一個語法糖，我們可以簡單測試下：

public class TypePatternMatching {
	public static void main(String[] args) {
		Object object = new Object();
		if (object instanceof String s) {
			System.out.println("a");
		}
	}
}

檢視編譯後的位元組碼：

public class test.TypePatternMatching {
  public test.TypePatternMatching();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: new           #2                  // class java/lang/Object
       3: dup
       4: invokespecial #1                  // Method java/lang/Object."<init>":()V
       7: astore_1
       8: aload_1
       9: instanceof    #7                  // class java/lang/String
      12: ifeq          28
      15: aload_1
      16: checkcast     #7                  // class java/lang/String
      19: astore_2
      20: getstatic     #9                  // Field java/lang/System.out:Ljava/io/PrintStream;
      23: ldc           #15                 // String a
      25: invokevirtual #17                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      28: return
}

可以看出，位元組碼其實和下面的寫法是一樣的：

public static void main(String[] args) {
    Object object = new Object();
    if (object instanceof String) {
        String s = (String)object;
        System.out.println("a");
    }

}

大家可以反編譯下這個 class，就能看出來。

Java 16 – Sealed Classes - Preview

Sealed Class 在 Java 17 已經發布了，相關的 JEP 如下：

• JEP 360: Sealed Classes (Preview)
• JEP 397: Sealed Classes (Second Preview)
• JEP 409: Sealed Classes

在某些情況下，我們可能想列舉一個介面的所有實現類，例如：

interface Shape { }
record Circle(double radius) implements Shape { }
record Rectangle(double width, double height) implements Shape { }

double area(Shape shape) {
	if (shape instanceof Circle circle)
		return circle.radius() * circle.radius() * Math.PI;
	if (shape instanceof Rectangle rect)
		return rect.width() * rect.height();
	throw new IllegalArgumentException("Unknown shape");
}

我們如何能確定我們列舉完了所有的 Shape 呢？ Sealed Class 這個特性為我們解決這個問題，Sealed Class 可以在宣告的時候就決定這個類可以被哪些類繼承：

sealed interface Shape permits Rectangle, Circle {}
record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}
double area(Shape shape) {
	if (shape instanceof Circle circle)
		return circle.radius() * circle.radius() * Math.PI;
	if (shape instanceof Rectangle rect)
		return rect.width() * rect.height();
	throw new IllegalArgumentException("Unknown shape");
}

Sealed Class （可以是 abstract class 或者 interface ）在宣告時需要指定所有的實現類的名稱。針對繼承類，有如下限制：

• Sealed Class 的繼承類必須和 Sealed Class 在同一個模組下，如果沒有指定模組，就必須在同一個包下
• 每個繼承類必須直接繼承 Sealed Class，不能間接繼承
• 每個繼承類必須是下面三種之一：
  • final 的 class，Java Record 本身就是 final 的
  • sealed 的 class，可以進一步指定會被哪些子類實現
  • non-sealed 的 class，也是一種擴充套件，但是打破 Sealed Class 的限制，Sealed Class 不知道也不關心這種的繼承類還會有哪些子類。

舉個例子即：

sealed interface Shape permits Rectangle, Circle, Triangle, WeirdShape {}
	
record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}


sealed interface Triangle extends Shape permits RightTriangle, NormalTriangle {}
record RightTriangle(double width, double height) implements Triangle {}
record NormalTriangle(double width, double height) implements Triangle {}

static non-sealed class WeirdShape implements Shape {}
class Star extends WeirdShape {}

double area(Shape shape) {
	if (shape instanceof Circle circle)
		return circle.radius() * circle.radius() * Math.PI;
	if (shape instanceof Rectangle rect)
		return rect.width() * rect.height();
	if (shape instanceof RightTriangle rt)
		return rt.width() * rt.height() / 2;
	if (shape instanceof NormalTriangle nt)
		return nt.width() * nt.height() / 2;
	throw new IllegalArgumentException("Unknown shape");

}

如果結合 Pattern Matching for switch 這個特性，就能實現更加方便的寫法，但是目前 Java 17 中，Pattern Matching for switch 還處於 Preview：JEP 406: Pattern Matching for switch (Preview)。我們需要在編譯引數和啟動引數中加上 --enable-preview，這樣就能像下面這樣寫程式碼：

double area(Shape shape) {
	return switch (shape) {
		case Circle circle -> circle.radius() * circle.radius() * Math.PI;
		case Rectangle rect -> rect.width() * rect.height();
		case RightTriangle rt -> rt.width() * rt.height() / 2;
		case NormalTriangle nt -> nt.width( ) * nt.height() / 2;
		default -> throw new IllegalArgumentException("Unknown shape");
	};

}

Java 16 – Stream API 更新

Java 16 中針對 Stream API 有兩個更新，這裡先提一個題外話，如果想看 JDK 不同版本之間有何差異，增加或者刪除了哪些 API，可以通過下面這個連結檢視：

• https://javaalmanac.io/jdk/17/apidiff/11/

路徑中的兩個版本就是要對比的兩個版本，其介面如下：

同時，我們也可以通過 JDK 內建 jdeps 工具查詢過期以及廢棄API以及對應的替換

jdeps --jdk-internals -R --class-path 'libs/*' $project

libs是你的所有依賴的目錄，$project是你的專案jar包，示例輸出：

...
JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.misc.BASE64Encoder                   Use java.util.Base64 @since 1.8
sun.reflect.Reflection                   Use java.lang.StackWalker @since 9

關於這個更新，我寫了一篇文章進行解析：Java 16 中新增的 Stream 介面的一些思考，核心內容總結如下：

假設有郵件這個 Record 類，包含 id，以及傳送到的郵箱和抄送到的郵箱：

record Mail(int id, Set<String> sendTo, Set<String> cc) {}

我們想找到一批郵件的所有不同的聯絡人，最後放到一個 List 中，可能會這麼寫：

Set<String> collect = mails.stream().flatMap(mail -> {
	Set<String> result = new HashSet<>();
	result.addAll(mail.sendTo());
	result.addAll(mail.cc());
	return result.stream();
}).collect(Collectors.toSet());

但是，這樣寫顯然很不優雅，首先是對於每一個 Mail 都建立了額外的 Set 和對應的 Stream，並且，對於每個 mail 的 sendTo 還有 cc 都遍歷了兩遍（addAll 一遍，後續 Stream 又一遍）。其實我們的目前只是將 mail 中的 cc 以及 sendTo 取出來，用於參與後續的 Stream。在這種場景下，就非常適合用 mapMulti：

Set<String> collect = mails.stream().<String>mapMulti((mail, consumer) -> {
	mail.cc().forEach(consumer::accept);
	mail.sendTo().forEach(consumer::accept);
}).collect(Collectors.toSet());

可以看出：

• mapMulti 的入參是一個 BiConsumer，其實就是使用其引數中的 consumer 接收參與 Stream 後續的物件
• mapMulti 的思路就是將引數中的需要參與後續 Stream 的物件傳入 consumer 來繼續 Stream
• consumer 沒有限制物件型別，想要限制必須加上形參 <String> 否則最後返回的是 Set<Object> 而不是 Set<String>

對於 Stream 增加了 toList 直接轉換成 List，由於不涉及 collect 裡面的截斷操作，所以比 collect 佔用的記憶體更小，需要的操作更少並且更快。之前轉換成 List，需要 collect(Collectors.toList())，生成的 List 是 ArrayList，是可變的。但是這次新加的 Api，toList 生成的是 UnmodifiableList，是不可變的。所以這兩個 API 不能直接互相替換，需要做一些檢查確認沒有更改才能替換。

Java 16 – HTTP/2 API

Java 16 中還引入了兩個關於 HTTP/2 API 的 JDK 補充，參考：

• JDK-8252304: Seed an HttpRequest.Builder from an existing HttpRequest
• JDK-8252382: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher

Java 16 – Unix Domain Sockets

相關 JEP：

• JEP 380: Unix-Domain Socket Channels

Unix domain sockets 以本地檔案的形式命名，讓我們可以像訪問本地檔案一樣訪問本地網路連線。這個用於在同一個機器部署的不同程式之間的通訊，下面是一個簡單的 BIO 的例子：

//建立 UnixDomainSocketAddress
Path socketFile = Path.of("/home/zhanghaxi/process1");
UnixDomainSocketAddress address = UnixDomainSocketAddress.of(socketFile);

//服務端監聽
ServerSocketChannel serverChannel = ServerSocketChannel.open(StandardProtocolFamily.UNIX);
serverChannel.bind(address);
SocketChannel channel = serverChannel.accept();

//客戶端連線

SocketChannel channel = SocketChannel.open(StandardProtocolFamily.UNIX);
channel.connect(address);

關於 NIO 的例子，請參考：https://docs.oracle.com/en/java/javase/16/core/internet-protocol-and-unix-domain-sockets-nio-example.html

相比於 TCP/IP 本地迴環連線訪問，由於 Unix Domain Sockets 知道他訪問的是本地程式，所以減少了很多檢查與校驗（例如定址與路由），同時由於不用做這些檢查，包的大小也要小一些。支援 Unix Domain Sockets 的作業系統有 Linux, MacOS 和 Windows 10 以上的版本以及 Windows Server 2019 以上的版本.

Java 16 – Project Panama (Incubating)

Project Panama 是一個讓 Java 變得更全面的專案，目前還處於孵化中的狀態。他目前主要包括以下三個 API：

• Vector API：讓 Java 也能使用新的 CPU 指令例如 SIMD（Single Instruction Multiple Data）相關指令來優化計算速度
• Foreign Linker API：讓 Java 可以直接呼叫系統庫，不用通過 JNI 再封裝一層。
• Foreign-Memory Access API：讓 Java 可以直接操作外部記憶體，突破現有對外記憶體 API 的限制，同時也是可以整合統一現有堆外記憶體操作的 API。

Vector API

相關 JEP：

• JEP 338: Vector API (Incubator)
• JEP 414: Vector API (Second Incubator)：Java 17 中的
• JEP 417: Vector API (Third Incubator)：Java 18 中的

其中最主要的應用就是使用了 CPU 的 SIMD（單指令多資料）處理，它提供了通過程式的多通道資料流，可能有 4 條通道或 8 條通道或任意數量的單個資料元素流經的通道。並且 CPU 一次在所有通道上並行組織操作，這可以極大增加 CPU 吞吐量。通過 Vector API，Java 團隊正在努力讓 Java 程式設計師使用 Java 程式碼直接訪問它；過去，他們必須在彙編程式碼級別對向量數學進行程式設計，或者使用 C/C++ 與 Intrinsic 一起使用，然後通過 JNI 提供給 Java。

一個主要的優化點就是迴圈，過去的迴圈（標量迴圈），一次在一個元素上執行，那很慢。現在，您可以使用 Vector API 將標量演算法轉換為速度更快的資料並行演算法。一個使用 Vector 的例子：

//測試指標為吞吐量
@BenchmarkMode(Mode.Throughput)
//需要預熱，排除 jit 即時編譯以及 JVM 採集各種指標帶來的影響，由於我們單次迴圈很多次，所以預熱一次就行
@Warmup(iterations = 1)
//單執行緒即可
@Fork(1)
//測試次數，我們測試10次
@Measurement(iterations = 10)
//定義了一個類例項的生命週期，所有測試執行緒共享一個例項
@State(value = Scope.Benchmark)
public class VectorTest {
	private static final VectorSpecies<Float> SPECIES =
			FloatVector.SPECIES_256;

	final int size = 1000;
	final float[] a = new float[size];
	final float[] b = new float[size];
	final float[] c = new float[size];

	public VectorTest() {
		for (int i = 0; i < size; i++) {
			a[i] = ThreadLocalRandom.current().nextFloat(0.0001f, 100.0f);
			b[i] = ThreadLocalRandom.current().nextFloat(0.0001f, 100.0f);
		}
	}

	@Benchmark
	public void testScalar(Blackhole blackhole) throws Exception {
		for (int i = 0; i < a.length; i++) {
			c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
		}
	}

	@Benchmark
	public void testVector(Blackhole blackhole) {
		int i = 0;
		//高於陣列長度的 SPECIES 一次處理資料長度的倍數
		int upperBound = SPECIES.loopBound(a.length);
		//每次迴圈處理 SPECIES.length() 這麼多的資料
		for (; i < upperBound; i += SPECIES.length()) {
			// FloatVector va, vb, vc;
			var va = FloatVector.fromArray(SPECIES, a, i);
			var vb = FloatVector.fromArray(SPECIES, b, i);
			var vc = va.mul(va)
					.add(vb.mul(vb))
					.neg();
			vc.intoArray(c, i);
		}
		for (; i < a.length; i++) {
			c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
		}
	}

	public static void main(String[] args) throws RunnerException {
		Options opt = new OptionsBuilder().include(VectorTest.class.getSimpleName()).build();
		new Runner(opt).run();
	}
}

注意使用處於孵化的 Java 特性需要加上額外的啟動引數將模組暴露，這裡是--add-modules jdk.incubator.vector，需要在 javac 編譯和 java 執行都加上這些引數，使用 IDEA 即：

測試結果：

Benchmark               Mode  Cnt         Score         Error  Units
VectorTest.testScalar  thrpt   10   7380697.998 ± 1018277.914  ops/s
VectorTest.testVector  thrpt   10  37151609.182 ± 1011336.900  ops/s

其他使用，請參考：fizzbuzz-simd-style，這是一篇比較有意思的文章（雖然這個效能優化感覺不只由於 SIMD，還有演算法優化的功勞，哈哈）

Foreign Linker API

相關 JEP：

• JEP 389: Foreign Linker API (Incubator)
• JEP 412: Foreign Function & Memory API (Incubator)：在 Java 17 中，和 Foreign Linker API 整合到了一起
• JEP 419: Foreign Function & Memory API (Second Incubator)：位於 Java 18 中

通過這個 API，我們可以使用純 Java 程式碼來呼叫系統的庫，例如使用 Java 程式碼彈出一個 Windows 提示框：

以上例子來自於 https://headcrashing.wordpress.com/2021/02/06/spare-keystrokes-with-the-record-keyword-modern-java-jdk-16-head-crashing-informatics-26-2/ ，感興趣的可以檢視下

Foreign-Memory Access API

• JEP 370: Foreign-Memory Access API (Incubator)
• JEP 383: Foreign-Memory Access API (Second Incubator)
• JEP 393: Foreign-Memory Access API (Third Incubator)
• JEP 412: Foreign Function & Memory API (Incubator)：在 Java 17 中，和 Foreign Linker API 整合到了一起
• JEP 419: Foreign Function & Memory API (Second Incubator)：位於 Java 18 中

很多流行的高效能 Java 框架和中介軟體使用了堆外記憶體，但是目前 Java 中操作堆外記憶體的 API 不夠完善：

• ByteBuffer API 可以提供直接記憶體的訪問 (DirectBuffer 還有 MMAP Buffer)，但是大小受限（2 GB，原因因為 Buffer classes limited by 32-bit addressing），並且有很多問題遺留了很多年未能解決，例如：MappedByteBuffer.release()/close() to release system resources，Please make DirectByteBuffer performance enhancements, Add absolute bulk put and get methods
• Unsafe API：效能很高，可以被 JIT 優化，但是沒有限制記憶體訪問，哪一塊記憶體都能訪問，如果訪問到一塊已經釋放的記憶體，就會導致 JVM 崩潰。
• JNI 呼叫：效能較差，因為無法被 JIT 優化（例如方法內聯）

如果這些 API 開發完成，使用 Java 操作記憶體將更加容易理解和高效

Java 16 – JDK Flight Recorder

JFR 是我最喜歡的 Java 特性功能，我針對 JFR 寫了很多篇文章，使用 JFR 定位過很多效能瓶頸以及線上問題，請參考以下系列或者文章：

• JFR 全解系列
• JFR導致的雪崩問題定位與解決
• JFR 定位因為 SSL 導致 CPU Load 飈高的問題
• 一次鞭辟入裡的 Log4j2 日誌輸出阻塞問題的定位
• spring-data-redis 上百萬的 QPS 壓力太大連線失敗，我 TM 人傻了

Java 16 中，針對 JFR， 在 Java 14 引入的 JFR Stream 的基礎上，增加了通過 JMX 暴露的 JFR Stream。原來我們只能內部消費處理 JFR Event，現在可以通過 JMX 遠端消費 JFR Event：JDK-8253898: JFR: Remote Recording Stream

Java 16 – jpackage

相關 JEP：

• 已廢棄 JEP 311: Java Packager API & CLI
• JEP 343: Packaging Tool (Incubator)
• JEP 392: Packaging Tool

這個是將 Java 程式打包成可安裝包的工具，目前支援的作業系統以及格式包括：

• Linux: deb and rpm
• macOS: pkg and dmg
• Windows: msi and exe

可以參考這個文章試用下：Building Self-Contained, Installable Java Applications with JEP 343: Packaging Tool

Java 16 - Performance

效能相關的更新有很多

Hotspot 實現 Elastic Metaspace

相關 JEP： Elastic Metaspace

原來的元空間實現中，每個類載入器佔用一個單獨的元空間抽象，當類載入器被回收後，這塊記憶體被釋放但是不會退還給系統而是繼續給其他類載入器複用，元空間的系統記憶體佔用只會一直增大不會縮小，也就是不會將記憶體退還給系統。現在優化了這一點，可以動態伸縮元空間。這塊的詳細原始碼分析，我會在之後出一期類似於 全網最硬核 TLAB 解析 的文章解析這塊。

G1 和 Parallel GC 優化

如果想詳細瞭解這塊的優化，可以參考這篇文章：JDK 16 G1/Parallel GC changes

ZGC 優化

相關 JEP：

• JEP 376: ZGC: Concurrent Thread-Stack Processing

ZGC 本來已經基本將 GC 每個階段都做成併發的了，GC 根掃描還是需要 STW。這個 JEP 優化了 GC 根掃描中的執行緒棧掃描，讓這個掃描也可以 “半並行化” 了。這塊我也會在日後進行詳細的分析。

Shenandoah GC 優化

• Shenandoah: should not block pacing reporters
• Shenandoah: reconsider free budget slice for marking
• Shenandoah: pacer should wait on lock instead of exponential backoff
• Shenandoah: support manageable SoftMaxHeapSize option
• Shenandoah: Concurrent weak reference processing
• Shenandoah: "adaptive" heuristic is prone to missing load spikes

Java 16 – Security

關於安全性相關的優化，請參考：JDK 16 Security Enhancements

Java 16 – Deprecations/Limitations

Primitive Wrapper Warnings

相關 JEP：

• JEP 390: Warnings for Value-Based Classes

這是一個令人激動的更新，是為了我期待已久的 Project Valhala 做鋪墊的（對，就是我之前把 Record 誤會了的那個）。

目前，原始型別的封裝型別類（例如 Integer ）的構造器標記為了過期，並且會在將來的版本被移除，用他們裡面的靜態方法 valueOf() 代替。

我單獨寫了一篇文章來分析這個，參考：JEP解讀與嚐鮮系列4 - Java 16 中對於 Project Valhalla 的鋪墊

Strong Encapsulation By Default

相關 JEP：

• JEP 396: Strongly Encapsulate JDK Internals by Default
• JEP 403: Strongly Encapsulate JDK Internals：Java 17 釋出的，已經完全去掉了 --illegal-access，如果使用，會有 OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=warn; support was removed in 17.0 的提示。

為了推進 Java 模組化，針對 --illegal-access 的特性進行了修改。Java 16 之前預設是 permit，遇到訪問沒有開放的包會在第一次有提示，但是還是可以正常執行：

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by j9ms.internal.Nimbus
	(file:...) to constructor NimbusLookAndFeel()
WARNING: Please consider reporting this
	to the maintainers of j9ms.internal.Nimbus
WARNING: Use --illegal-access=warn to enable warnings
	of further illegal reflective access operations
WARNING: All illegal access operations will be denied
	in a future release

Java 16 則是 deny。即預設禁止非法包訪問，使用者可以通過啟動引數 --illegal-access=permit 修改。Java 17 則是移除了這個引數，加上這個啟動引數也無效了，會有提示並且反射訪問內部未暴露的包會報錯，例如：

var dc = ClassLoader.class.getDeclaredMethod("defineClass",
		String.class,
		byte[].class,
		int.class,
		int.class);
dc.setAccessible(true);

使用啟動引數--illegal-access=warn 執行：

OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=warn; support was removed in 17.0
Exception in thread "main" java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @378bf509
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
	at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)

但是，通過啟動引數 --add-opens java.base/java.lang=ALL-UNNAMED 還是可以打破封包控制.