Java編程語言是一個野獸，與其他花哨的語言不同，它是慢慢演化成今天的樣子的。這也不是件壞事，因為以Java開發的速度，有很多的警告，只有在多年的經驗基礎上才能被搞定。Java工程師需要跟隨java語言的發展來不斷擴展實踐技能，才能在IT行業長久立足！
方法/步驟
不要信任你早期SPI演化的結論
給客戶提供SPI是一個簡單的方式讓他們在庫或者代碼中注入自定義的行為。但是請注意，你的SPI演化結論可能會欺騙你，讓你覺得你可能（不再）需要那個參數。是的，任何功能都不應過早的加入。但是一旦你發佈了你的SPI並且你決定遵循語義的版本控制，你就會後悔自己在SPI中加了一個愚蠢的，只有一個參數的方法，你意識到在某些情況下你還需要另一個參數：
開始寫SAMs吧（single abstract method)單個抽象方法
Java8已經在敲門了。無論你喜歡與否，Java8會帶來lambdas表達式。但你的API使用者可能會喜歡他們，你最好是確認他們可以儘量多的使用這些。因此，如果你的API不接收簡單的“標量”類型類如int, long, String, Date, 那麼就讓你的API儘量多地接收SAMs吧。
什麼是SAM? SAM是Single Abstract Method[Type], 即單一抽象方法，也稱作函數式接口（Functional Interface）。它即將使用@FunctionalInterface註解。這與規則2並無出入，因為EventListener實際上就是一個SAM. 最好的SAM應該只有一個參數，進而可以簡化為一個lambda表達式
API方法永遠不要返回null數組或null鏈表
檢查null值有必要嗎？大多數I/O操作產生的是IOException，但是這個返回了null，Null不能保存任何錯誤信息來說明為什麼會發生這個I/O錯誤。所以這裡錯在三方面：
Null無助於找到錯誤。
Null並不能區分是I/O錯誤還是文件的實例不能表示一個目錄。
在這裡，任何人都記不住這個null。在collection contexts（集合上下文）中，“absence”（缺席）的概念最好使用空的數組或集合來實現。除非是延遲初始化，否則“缺席”數組或集合幾乎從不使用。
默認把方法設為final有些人並不同意這一點，因為默認把東西設為final跟java程序員們通常所作的格格不入。但是如果你對於源代碼有完全的控制，默認把方法設為final絕對不會有任何錯，因為：
如果你需要重寫一個方法（真的需要麼？），你仍可以刪掉final關鍵詞。
你永遠不會意外地重寫某個方法。
記住C++的析構函數
要記住C++的析構函數（C++ destructors）？不想這樣做？那你得很幸運以至於從來不需要調試那些由於分配內存而沒有在對象移除後釋放內存而導致內存洩露的代碼。感謝Sun/Oracle實現了垃圾回收機制。