@千里冰封
我覺得引用代碼沒什么不可以，頂你

每個國家的國情不一樣，google就是公司，瞎拽什么？

@apple.shan
沒關系，隨便起的名字。

@零全零美
不錯的建議，謝謝關注！

也許，工作流，適合流程復雜的情況，或者流程經常改變的情況。用程序代碼不足以靈活設計或者修改流程，所以有必要采用工作流。

謝謝！很好的思路。

思路不錯，不過深度和系統性可能還應該再好一些。

性能應該大大不如直接通過bean自己的get set方法得到屬性值吧？

為什么不考慮一下服務自己？

非常感謝！

@戰爭與和平
其實就是一個再封裝的問題，將復雜的東西封裝起來。簡化上層邏輯并使之清晰。

Thank you very much!

@letitbe
那...好吧

@kk
這個版本是可以的，經使用，還是不錯滴。

說得好，樓豬是在找罵。

最新版的NetBeans 6.5 m1開發Java就超爽，其自帶的GUI設計就跟VS 2005一樣，其功能也開始超越Eclipse 3.4版，我相信NetBeans 6.5以后正式版本會更好更出色！我已經從Eclipse 3.4轉到NetBeans平臺上了，原來Eclipse開發過的項目可以很輕松地導入到NetBeans平臺中來，爽吧！

我最近也遇到了這個問題所以才看到你的這篇文章 呵呵 !

@愛好編程
應該怎么做才有版權意識？我已經標注了文章出處了。
另外，我也加上了自己的一些標注，是便于自己記錄的。
而且，我是在尋找了很多方法之后，經過此法才成功的，記錄下來，有什么不對嗎？

@paul
“BOM——Byte Order Mark，就是字節序標記。在這里找到一段關于BOM的說明：

在UCS 編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸字節流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。這樣如果接收者收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little- Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。

UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。Windows就是使用BOM來標記文本文件的編碼方式的。”

我的理解，BOM就是一些附加信息，實際上不屬于數據內容。

很好的文章，通俗易懂。

通俗易懂，學習。謝謝！

......和什么樣的人在一起你自然也會成為什么樣的人。“蓬生麻中，不扶而直，白沙在涅，與之俱黑”。......
本文有很多類似的金玉良言，我認為這是一篇每一位程序員都值得收藏的佳作。

逐字逐句讀完后，感覺文章寫得條理清晰，并在內容上一點點將一個程序員內心的普遍疑惑做了經驗性的總結。最有收獲的是讀到最后，忽然感覺到作為一個程序員，其實是可以成為比較強勢的一個群體的，增強了不少信心。前提是要努力。很喜歡的一句話——“相對于其它職業，程序員對自己命運的把握程度更大。榮辱自取，不求于人。”

筆誤了！

Sorry!
這個東西大家根據情況使用吧。

只是自己做做記錄，方便用的。

@myy
哦，是嗎？多謝了！
對不起大家，沒負責任！
另外，這個不是原創。:)

不錯！

@王能
不知道你是否在開玩笑 :)
我這里談的是針對方法的性能測試，你說的當然需要另外的一套理論和技術。

@久城
謝謝你的建議！

@ohopen.com
收藏的文章，不是俺寫地，呵呵。

@過河卒
說得很對，呵呵，添加jre是需要的。
不過這里只是個筆記而已，只是記錄了必要的打包操作步驟，jre是必須的。

@dennis
其實，這個題目不是我寫的，只是心中有疑問，看到晚上有此討論，就粘貼上了。我的意思是想問，對于工具類，用一個實例實現和用靜態類實現的優劣。
其實你也應該知道我要說的是什么問題。請幫忙談談你的理解吧。謝謝！

不知道有沒有太多的bug :)