編譯環境(jdk)
編譯環境沒有什么可講的, 我只用過 sun jdk , 不知道其他的編譯器用起來是什么感覺.
有興趣的朋友可以用用其他的編譯器, 再來分享自己的經驗.

需要注意的是有時候你會需要用混淆器來編譯項目, 由于 class 代碼比較容易
被反編譯為 java 代碼, 為了保護自己(或公司)的果實, 有時候需要使用這種
工具. (當然對于開源項目就完全不必要了:))

提到了混淆器當然就要提反編譯器了, 最著名的應該就是 jad 了吧. 假如你
想研究別人的代碼卻又得不到源碼時, 這個工具還是非常不錯的.

另外, 蔡學鏞先生的"java夜未眠"中有篇文章: java 相關的編譯技術.

編輯環境(vim)
我對 ide 環境的感覺不太好. 以前沒有用過, 以后應該也不會用.
我最喜歡的編輯環境是 vim. 它真的是一個非常強大的編輯器, 這一點已經有
無數的人證明過了, 就不用我羅嗦了:)

使用 vim 編輯 java 文件需要兩個方面:

• 熟練使用 vim 編輯普通的文本文件
  不熟悉的朋友可以從這篇文章中獲得一些技巧.
  

• 在 vim 里面使用特殊技巧支持 java 文件的編輯.
  不熟悉的朋友可以從這篇文章中獲得一些經驗.
  

項目管理(ant)
ant 是個基于 java 的構建工具, 配置 ant 就是配置 build.xml 這個 xml 文件,
配置好后, 它就會替你完成許多任務, 特別有些任務很煩瑣.

我是這樣使用 ant 的.

代碼檢查(checkstyle)
程序員一般都有自己的編碼風格, 但是現在是一個強調團隊而不是英雄的時代, 所以
代碼風格的一致性是非常重要的, 我們免不了要查看別人的代碼, 自己的代碼也免
不了要給別人查看. 至少, 在同一個團隊中能保證代碼的一致性, 這樣會讓我們在處理
任意代碼時都感覺是自己寫的一樣. checkstyle 幫我們實現了這一點, 只要你在編碼
時堅持用它來檢查一下.

在 ant 的使用文章中提到了如何與 checkstyle 集成.

單元測試框架(junit, httpunit, cactus..)
程序編寫完以后就要進行測試(這里主要指的是單元測試).
進行單元測試是一般程序員不愿意做的事, 不過這個事情真的很有用.
這里給大家介紹幾篇文章:

• 應用JUnit實施單元測試
  文章介紹了測試的概念及如何使用 junit, 還有 junit 最佳實踐
  

• 怎樣使用Junit Framework進行單元測試的編寫
  文章介紹了編寫單元測試的原則及如何進行
  

• JUnit Test Infected: Programmers Love Writing Tests
  junit 的文章
  

• 使用HttpUnit進行集成測試
  介紹怎么使用 httpunit 的文章, 找 sun 技術社區的那篇原創文章, 寫得很明白.
  

• 關于 cactus 的使用, 網絡上也有不少文章, 但是我還沒有找到特別好的文章.
  

調試環境(JSwat)
測試失敗后往往需要調試看看了. 上次漏掉了這個部分, 其實對于調試部分我沒有
太多的經驗, 以前的調試大部分建立在輸出的基礎上完成的.
不過在調試過程不容忽視, 有一個開源的軟件: JSwat 能夠滿足大部分的調試要求,
可以在這里找到它.

代碼版本控制(cvs)
代碼的版本控制十分重要, 有了這樣一個代碼庫, 硬盤突然崩掉也不怕了:)
介紹安裝使用的文章不可勝數.
這里是我的安裝過程簡敘.
這里是簡單使用說明.
這里是 cvs 手冊.

bug 跟蹤(Bugzilla)
Bugzilla是一個bug追蹤系統，用以管理bug提交、bug消除，不僅能降低同樣錯
誤的重復發生，提高開效率，而且有助于項目管理的難度。(摘自竹筍炒肉)
更重要的, 它是一個開源軟件:)
這里是我寫的簡易安裝步驟.
這里是它的使用說明.

壓力測試(Jmeter)
軟件部署以后往往就會有執行效率上的要求:
程序耗費多少的系統資源? 需要用什么樣的服務器來支撐? 等等
使用 Jmeter 可以告訴你一些數字及圖表, 可以判斷軟件的負載能力
使用 weblogic 的 JRocket 運行環境則能夠得到軟件運行時對系統資源的使用信息.

中間工具
java 的中間工具有很多, 著名的是各種的 j2ee 容器, 各種應用框架及各種
數據持久化方案. 這里列出一些著名的, 以便查找.