Java on Mac OS X


現況

到官網下載 Java SE 6 的話,會找不到下載的連結(只有 Linux、Solaris 跟 Windows),而且也不會有任何提示,那是因為 Apple 有開發 自家的 JVM (Java for Mac OS X),但如果是下載 Java SE 7 的話,會看到下面的提示:

Looking for the JDK7 for Mac OS X Developer Preview? The JDK7 for Mac OS X Developer Preview for Java Developers is now available on jdk7.java.net.

會有這樣的差別是因為 Apple 在發行 Java for Mac OS X 10.6 Update 3 時,突然宣佈不再開發自己的 JVM(但 Mac OS X 10.5 跟 10.6 預裝的版本還是會繼續維護)。這個消息一出,不免讓人聯想到繼 Flash 之後,Java 會不會是下一個要被搞掉的平台?

所幸下一個版本 Mac OS X 10.7 只是沒有預先安裝 JVM 而已,使用者第一次存取 Lanuchpad > Utilities > Java Preferences 或其他 Java 應用程式時,就會被提示是否要下載安裝 JVM,安裝的還是 Apple 自家的 JVM (Java SE 6 Update 29)。不過之後 Java SE 7 就必須從 Java 官網下載,也就是說 Mac 上的 JVM 不會再比其他 OS 慢半拍了。

Apple 在宣佈不再開發自家 JVM 的消息後(2010-10),過了不久(2010-11)又隨即宣佈加入了 OpenJDK,全力支援 JDK7 for Mac OS X 的開發(Mac OS X Port Project,在 BSD port 上加上 Apple 專屬的部份)。巧的是,在 Apple 宣佈加入 JDK 的前一個月,同樣有自家 JVM 的 IBM 也宣佈棄守 Apache Harmony 並加入 OpenJDK,因此 OpenJDK 有 Oracle/IBM/Apple 三大廠在背後撐腰,再加上直接做為 Java reference implementation (RI),前途一片看好。

Note

參考資料


安裝

在 Mac OS X Lion 下,點選 Launchpad > Utilities > Java Preferences,如果還沒有安裝 Java 的話就會跳出提示詢問是否要安裝,之後就會自動下載安裝 Java for Mac OS X 10.7 Update 1 (Java SE 6 to 1.6.0_29)。

另外第一次執行 Java 時,也會被提示要安裝 Java:

$ java
No Java runtime present, requesting install

確認安裝的結果:

$ java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
Note

參考資料

推薦 Java 反組譯(Java Decompiler)工具

過程中才發現 JAD (JAva Decompiler) 過去在這個領域的重要性,許多工具底層都是以 JAD 做為 decompiling engine:

但 JAD 的官網從 2009-05 後就連不上(這裡還有 mirror),而且這個套件已經沒在維護了,最多只支援到 JDK 1.3 的 .class 檔。

目前知道能支援比較新 JDK .class 的工具只有 Java Decompiler (JD;剛好跟 DJ Java Decompiler 的 “DJ" 相反):


JD | Java Decompiler - JD-Core、JD-GUI 與 JD-Eclipse

The Java Decompiler Project 由 JD-Core、JD-GUI 還有 JD-Eclipse 組成,其中 JD-Core 做為 JD-GUI 跟 JD-Eclipse 的底層。除了 JD-Eclipse 之外,JD-Core 跟 JD-GUI 都是用 C++ 開發的,因此 JD-Core 跟 JD-GUI 在執行期都用不到 JRE。

這個專案的初衷就是要 decompile/analyze Java 5+ 的程式碼(事實上它支援 JDK 1.1.8 到目前最新的 1.7.0),支援 annotations 跟 generics 等語言的新特性。

JD 支援 Windows、Linux 及 Mac OS X 多個平台,甚至還提供了一個線上體驗的版本,只要將 .class 拖進瀏覽器,就會自動做 decompile 的動作。

JD-GUI 提供了很多實用的功能:

  • 除了開啟 .class 之外,也支援直接開啟 Jar 檔。好處是:
    • 可以從 Type Hierarchy 裡看出某個 class 跟同一個 Jar 檔裡其他 class 的繼承關係。
    • 某個 class 如果有引用到同一個 Jar 檔裡其他的 class 時,點 class name 就會連往該 class 的原始碼,相當方便。
  • Navigate > Open Type Hierarchy… 可以瀏覽目前的 class 在 type hierarchy 裡是處於哪個位置。
  • 還有一項特異功能,就是可以解析 .log 檔(Edit > Parse Log)。只要將帶有 stack trace 的 log 貼到視窗裡,點 class name 就會連往該 class 原始碼。

加上 JD-GUI 本身免安裝,使得它很適合在 production 環境下做 debuging 的工作,不需要花時間把對應的原始碼傳到 production 的機器上,尤其是 exception 是從 third-party 套件丟出來時。另外,JD 也透過 JD-Eclipse 提供了開發時期 debugging 的支援。

JD 可以用在非商業用途上,只要不將它包進商用軟體即可。

其他工具還有:


參考資料

Why month in Java Date/Calendar is zero-based

以前從來沒有懷疑過為什麼 Java API 裡 java.util.Datejava.util.Calendar 的月份會是 zero-based. 以下這些資料給了答案: 因為當初, 所以現在…

這或許不是什麼太大的問題 (雖然這是個不該犯的錯), 反正只要記住月份跟別人不一樣, “規定" 是 zero-based 就好了… 直到自己想要開發一些跟日期時間有關的 library 時, 我遇到了與 JavaSoft 當初由 Date 提出 Calendar 時一樣的掙札 – 我的 API 要採 zero-based 或 one-based?

如果我採用 one-based, 就代表別人不能再用 Calendar 的常數來使用我的 API. 沒辦法, 只好跟著錯下去, 因此最後我還是決定一起淌這個混水, 採用 zero-based

這真是太可怕了, 不得不警惕自己在規劃 API 時一定要很謹慎, 因為 API 這種東西一旦對 caller 承諾了, 就難以收回… 真是一言既出、駟馬難追!!