很多人在談論內存泄露問題，當然對于c/c++來說，這個應該是老掉牙的問題，但是很多Java人員也越來越多得討論這個問題，我這里寫個小結，希望對大家有一定的參考價值。篇幅較長，詳細內容請進
這里。
Jbuilder是Borland公司開發的java開發的工具，而JDeveloper是Oracle公司提供給大家使用的IDE工具，最近的開發過程中分別使用了這兩種工具，現在來談一下自己在設計和開發的過程中發現的兩種工具的不同，并對兩種工具提供的功能做一個簡單的比較，希望與大家共同交流。
一、UML設計：在開發之前，我們首先想到使用UML對所要開發的項目進行設計，以使自己在真正編碼的時候做到心中有數。在這個方面，JDeveloper比Jbuilder有著天然的優勢，因為在Jdeveloper中就包含了創建UML圖的工具，我們可以方便的在一個工具下進行UML的設計，并且在其中，從圖到代碼的轉換是自動完成的，而不需要我們手動的進行轉換，而且，所有的圖示與源代碼都是處于一個工程中的，這也方便了我們對整個工程的把握和管理。
而在Jbuilder的開發過程中，我們不得不借助與其他的工具進行UML設計，我們選擇的是Borland公司專門針對JBuilder的Together Designer for Jbuilder，然而，這個工具在一定程度上與我們的工程有些不協調的地方。我并不是說這個工具不如JDeveloper中的UML設計工具，相反，我覺得在很大程度上，尤其是方便易用的方面，Together Designer比JDeveloper有更大的優勢，一方面Together Designer 2005全面集成的針對UML 2.0的支持，我們可以在其中非常方面的建立UML的設計。（可惜我對UML2.0的理解還不太深入，沒有膽量使用，呵呵），另一方面，里面集成了一些模式的模板。哪些模式呢？那就是大家最熟悉的“四人幫”所提出的那些模式，這樣如果我們在設計過程中使用了設計模式的話，就可以方便的調用，而無需自己設計，這一點也是非常方便的。但是我們的設計是一個非常小的工程，我考慮了一下，但是暫時沒有發現可以使用設計模式的地方，可惜了這么好的功能。
另外，我個人覺得有一點二者是各有所長，那就是對參數的處理上，在JDeveloper中，所有的參數我們都需要手動輸入，并且可以在設計圖中顯示。而在Together Designer中，我們可以向在編制程序的過程中一樣，對一個操作的各項參數進行詳細的設計，但是所有的參數都不會顯示在圖上，這項功能我想每個人的看法都是不一樣的，如果說好，那么這樣的設計可以避免由于操作的描述太長，而在頁面顯示上出現問題。如果說不好，那就是我們在看UML圖的時候無法了解到其中參數的情況。
在設計的過程中，應該說二者是打了一個平手。
二、開發：這個方面我主要指的就是實際的編碼工作，在這個方面，Oracle作為數據庫方面的老大，當然對數據庫的支持方面為我們提供了很多的方便，但是正如大家所知道的，Borland所提供的開發工具都是以簡單易用、對用戶友好而出名的，在實際的開發過程中，在代碼自動完成，錯誤自動修正還有調試的過程中，JBuilder都提供了JDeveloper所不能提供的方便，這也是我們最終在開發的時候選擇了JBuilder的原因。
例如：當我們在代碼中使用了一個我們沒有引用的類的時候，JDeveloper只是簡單的為我們報錯，而不會給我們提供解決的方法，而在Jbuilder當中，我們可以方便的按下alt+enter來看提示，并在建議的改進方法中選擇自動修改我們的錯誤。或者在java開發中我們深惡痛絕的catch exception,有些操作由于沒有捕獲異常，而不能在編譯過程中通過，在JDeveloper中我們只能老老實實的添加try……catch，然而在Jbuilder中，我們同樣可以讓它自動完成這項功能。
在這個方面，應該說JBuilder在很大程度上獲得了勝利。
以上就是我在開發過程中對二者的使用的一個簡單的比較，可能在某些方面由于我沒有使用到而有些偏頗，希望能夠與大家一起討論。
更多Java技巧盡在
dev.yesky.com
本文介紹了軟件體系架構產生的背景和架構模式的基本理論。重點介紹管道與過濾器體系架構模式的結構，實現，優缺點等，然后以J2EE的Servlet Filter為例進行剖析它是怎樣應用該架構模式的，最后簡單闡述了在其它J2ee應用中(Jboss和Axis)的實踐。
全文閱讀：軟件體系架構模式在J2EE中的應用