當中最棒的一個特點將帶來一個全新的檔案系統的API集,
這個理由最主要是：
舊有的 API 過於陳舊, 功能角色定位不清, 且不太符合當今的多樣化作業系統,
例如 java.io.File 是在 JDK 1.0 大約十年前的作業系統時代背景下制定,
十年後的今天, 各家作業系統(OS)不斷演進, 有必要且有需要一個全新的API,
來接替 java.io.File 這位API老人家的工作 ...
來看看老魚的簡單例子先：
- OS：GNU/Linux Debian (unstable)
- JDK: 1.7.0-nio2 , HotSpot VM 14
- Groovy: 1.7 b1
首先我們用Linux下的文字編輯器 vi 來分別用 Java 與 Groovy 完成二個相同結果的程序,
用來判斷指定的檔案是否存在, 以 JDK 1.7 NIO2 實作：
Java版: 嚴行命名約定, 我們為這檔案取名 PathTest.java 與程序內class同名.
import java.nio.file.*;"審慎的"確定code沒問題後, 請出了 javac 來為我們編譯成靜態執行碼後,
class PathTest {
public static void main(String[] args) {
FileSystem fs = FileSystems.getDefault();
Path path1 = fs.getPath("/etc/hosts");
Path path2 = Paths.get("/etc/sysctl.conf");
System.out.println("path1 = " + path1.exists());
System.out.println("path2 = " + path1.exists());
}
}
執行它 ... 其實也沒什麼大事 @"@ 就印出二小行結果,
判斷二個指定的檔案是否存在於系統中:
path1 = true
path2 = true
Groovy 版: Scripting 命名是鬆散的, 隨便您取名例如 fish.groovy ...
來看看 Groovy 對 Java 做的改變
- 命名上可以是鬆散的, 型別也可以被省略
- 約規的宣告式也可以省略(public static void main())
- ; 分號可有可無
- 不需編譯過程可以直接執行, 開發速度上變快了
- 仍可選擇完全編譯成 java bytecode 執行
- Code 變的簡潔, 可更不需要依賴IDE, 僅用 vi
- Groovy 仍依附著Java, 不是替代是相輔合一
- 可使用全部JDK的特性, 但對Java開發者來說學習成本很低, 多為簡化式子
- 型別省略不代表它為弱型別Scripting, 由下面的 assert 可驗證
更多請見老魚獨立專案的持續分享
沒有留言:
張貼留言