minor.major version 詳解

從 JDK 1.1 到 JDK 1.7 編譯器編譯出的 class 的預設 minor.major version 吧。（又走到 Sun 的網站上翻騰出我從來都沒用過的古董來）

JDK 編譯器版本	target 參數	十六進位 minor.major	十進位 minor.major
jdk1.1.8	不能帶 target 參數	00 03   00 2D	45.3
jdk1.2.2	不帶(預設為 -target 1.1)	00 03   00 2D	45.3
jdk1.2.2	-target 1.2	00 00   00 2E	46.0
jdk1.3.1_19	不帶(預設為 -target 1.1)	00 03   00 2D	45.3
jdk1.3.1_19	-target 1.3	00 00   00 2F	47.0
j2sdk1.4.2_10	不帶(預設為 -target 1.2)	00 00   00 2E	46.0
j2sdk1.4.2_10	-target 1.4	00 00   00 30	48.0
jdk1.5.0_11	不帶(預設為 -target 1.5)	00 00   00 31	49.0
jdk1.5.0_11	-target 1.4 -source 1.4	00 00   00 30	48.0
jdk1.6.0_01	不帶(預設為 -target 1.6)	00 00   00 32	50.0
jdk1.6.0_01	-target 1.5	00 00   00 31	49.0
jdk1.6.0_01	-target 1.4 -source 1.4	00 00   00 30	48.0
jdk1.7.0	不帶(預設為 -target 1.6)	00 00   00 32	50.0
jdk1.7.0	-target 1.7	00 00   00 33	51.0
jdk1.7.0	-target 1.4 -source 1.4	00 00   00 30	48.0
Apache Harmony 5.0M3	不帶(預設為 -target 1.2)	00 00   00 2E	46.0
Apache Harmony 5.0M3	-target 1.4	00 00   00 30	48.0

 

1) -target 1.1 時 有次版本號碼，target 為 1.2 及以後都只用主要版本號了，次版本號碼為 0
2) 從 1.1 到 1.4 語言差異比較小，所以 1.2 到 1.4 預設的 target 都不是自身相對應版本
3) 1.5 文法變動很大，所以直接預設 target 就是 1.5。也因為如此用 1.5 的 JDK 要產生目標為 1.4 的代碼，光有 -target 1.4 不夠，必須同時帶上 -source 1.4，指定源碼的相容性，1.6/1.7 JDk 產生目標為 1.4 的代碼也如此。
4) 1.6 編譯器顯得較為激進，預設參數就為 -target 1.6。因為 1.6 和 1.5 的文法無差異，所以用 -target 1.5 時無需跟著 -source 1.5。
5) 注意 1.7 編譯的預設 target 為 1.6
6) 其他第三方的 JDK 產生的 Class 檔案格式版本號碼同對應 Sun 版本 JDK
7) 最後一點最重要的，某個版本的 JVM 能接受 class 檔案的最大主要版本號不能超過對應 JDK 帶相應 target 參數編譯出來的 class 檔案的版本號碼。

上面那句話有點長，一口氣讀過去不是很好理解，舉個例子：1.4 的 JVM 能接受最大的 class 檔案的主要版本號不能超過用 1.4 JDK 帶參數 -target 1.4 時編譯出的 class 檔案的主要版本號，也就是 48。

因為 1.5 JDK 編譯時間預設 target 為 1.5，出來的位元組碼 major.minor version 是 49.0，所以 1.4 的 JVM 是無法接受的，只有拋出錯誤。

那麼又為什麼從 1.1 到 1.2、從 1.2 到 1.3 或者從 1.3 到 1.4 的 JDK 升級不會發生 Unsupported major.minor version 的錯誤呢，那是因為 1.2/1.3/1.4 都保持了很好的二進位相容性，看看 1.2/1.3/1.4 的預設 target 分別為 1.1/1.1/1.2 就知道了，也就是預設情況下1.4 JDK 編譯出的 class 檔案在 JVM 1.2 下都能載入執行，何況於 JVM 1.3 呢？（當然要去除使用了新版本擴充的 API 的因素）