今天找資料，碰巧看到，順便說說，呵呵，首先要表示感謝，你的文章讓俺看到了jdon的進化，jdon今天終于進化到他一開始就極力反對的模式了，這點是jdon當初讓很多人抓狂的核心。

你可能并不清楚當年很多人和benq的紛爭，其核心并不在于中國人自己做開源好不好，核心還是在于一個技術發展方向，和在此之上技術人員的職業道德操守。
實際上不少開源項目還是得到了國內一些人的認識， 比如springside，在javaeye上人氣就很旺，同樣是javaeye，各位牛人對benq就是一邊倒的態度

1. jdon的概念并不新，三四年前也不新。 當年在ejb的失敗已經成為定局的時候，benq還在極力鼓吹設計一個基于ejb應用的框架，而且層次結構劃分及其復雜，這是他讓很多人抓狂的最初原因，但是他更進一步讓人抓狂的原因是他的固執。 你可以找找看，他現在基本只在jdon發言，而且jdon并不允許任何有反對他的意見。
如果你有留心的話你會發現，5年前左右，ejb將死未死之時，真是大量此類框架涌現的時候。 另外， naning這個優秀的開源lib也是中國人做的，并得到了當時國外社區的認可。

2. jdon現在已經進化了， 基本上是copy spring的路子，而最初包括現在benq都是極力反spring的。 這基本是商業利益的問題， 就想當初他極力鼓吹ejb一樣，因為這是他的謀生手段。
jdon的核心和spring現在已經沒有本質區別，差別在于benq一個人無力完成類似spring這樣的大作，所以他只能再找一些開源的東西進行包裝。這注定他只能是一個追隨者，當然，他身后很多追隨的菜鳥也可以保證他的飯碗。

其實這樣一個級別的框架，是基本不可能靠一個人來開發維護的，benq的偏執又缺乏足夠的天賦，注定了jdon的悲劇。

3. jdon上曾經有一個程序員向benq請教如何保證自己的代碼不被有效反編譯，對這個問題的一般做法是使用混淆工具， 或者進一步在設計中加入陷進和偽裝類。 但是benq當時的回答是， 一個優秀程序員做出來的設計， 應該是讓人在沒有文檔的情況下，無法看懂源代碼，諸如jpetstore，tomcat都是這樣的。 如果這確實是benq的本意的話，你可以明白，他個人是更傾向于用復雜化的東西來表現簡單食物的，這是jdon最初的版本被人狂踩的一個原因。

另外ps一下，我認識的大部分程序員都具備在不用文檔的情況下讀懂jpetstore源代碼的能力，由此真是懷疑某人的iq。

4. benq本身對模式有很好的研究， 這也是早期他得到眾多網友賞識，并由此建立自己江湖地位的原因。但是任何事一旦走向過就莫名其妙了。從模式走向過度模式，到反模式，就比較悲哀了。
你也提到benq在模式的理解上，在代碼質量上，都超過一般的程序員，他這個人水平還是有一些的，但是大部分人不喜歡的是他的人品。

5 有件事可以說明benq的固執， 某次他和人爭執，在無法以理服人的情況下，他拿出自己用鼠標繪制的山水畫，意思是一個能有如此雅興和修養的人，道德品質肯定是高尚的，以此證明對方是錯誤的。到了3，4年前，他基本上已經拒絕和任何對他有不同意見的人進行辯論了。 有不同意見者刪帖，呵呵。

我大概認識benq8年了，呵呵。

有筆誤
系統類加載器：由于其負責加載虛擬機的核心類型
這里不應該是系統類加載器吧，應該是boostrap加載器。

@44you
跟預測無關吧，只是比較崇拜某些大師昧著良心說話賣東西的態度。 比如那個袁某，當時說這話的時候他們內部使用ejb開發的一個東西問題多多，開發人員私底下都跟我承認選擇ejb選錯了，為了商業利益還繼續大肆宣傳。

benq我最佩服的是他就是敢把某些明顯的謬論說成真理，諸如什么jpetstore的代碼一般人沒有文檔就根本讀不懂之類的瞎話。

@netrice
jprofile，jprobe我都用了很多年了。這2者根本不是一個概念， 我喜歡的是這種小東西，方便，易用，大部分功能都已經達到了，還要弄個盜版的大玩具來跑干嘛

有個東西叫jdic， 1.6的東西也都是從這個項目發展來。
用jdic可以很容易實現系統托盤，內嵌瀏覽器等功能， 不需要非1.6不可。

@mingkg21
用的jmm，j9聯網有點問題

@shrekwhoosah@gmail.com
example代碼里有，pipeserver， 你自己翻翻看
另外有個文檔也有講。

另外不知道lz用的jdbc是什么版本？ sqlserver 2000 的官方版本問題多多，印象中諸多特性都不支持。

pk的這么熱烈丫， 我想可能先要搞清楚的是行鎖，頁鎖和表鎖這些基本概念，搞清楚不同數據庫的鎖機制，然后再來談樂觀鎖還是悲觀鎖會比較容易理解。

我估計樓主缺少在sybase，db2下的工作經驗， 所以才會這么激動。不同數據庫的設計本身是有相當大差異的，很難說好壞，我印象中，缺省情況下對鎖的處理比較不傷腦筋的就是oracle了，其他的不管是sybase還是db2都不是缺省就可以很輕松做到高并發的，但是處理的好，至少db2 可以做到不輸給oracle的高并發。 至于sql server ，tpc網站上去翻一下，可以發現sql server也是常客。

但是早期oracle的開發， 嗯， 我覺得在很多方面其實倒不如db2這樣的數據庫省事，比如大表和小表在sql中的位置，都會顯著影響sql性能。再比如sql是簡單好，還是復雜好，這2個數據庫也是相反的。

這只能說明不同數據庫的機制是有很大差異的，用好一個數據庫需要點時間對他進行比較深入的理解。現代程序員往往被各種框架屏蔽了底層，有時候也不是什么好事，以前項目中就有專門組織DBA對程序員進行數據庫方面的培訓，目的也就是為了彌補這個問題。

對于鎖的問題，在oracle9i&10g編程藝術那本書里，作者有很深入的介紹，也列舉了其他數據庫的處理情況。作者從其他數據庫轉向使用oracle的時候，對這個問題，貌似和樓主一樣震驚，呵呵。當年我也有個項目，被db2的鎖機制，搞的的死去活來，呵呵。

簡單的說，搖身要是高可靠性數據庫都只是知道寫sql這么簡單， 人家DBA還怎么活？

@隔葉黃鶯
h2和sqlite的級別不一樣，這么說吧，我平時開發是使用h2來代替oracle，db2， mysql這些企業用數據庫的， 而用sqlite就比較難。比如如果你的目標數據庫是db2，開發中又使用到一些java或c的函數，用h2只要使用java方法代替就可以了。

而h2的文件這么多個，也是從產品應用級別角度的考慮，方便恢復和跟蹤問題。

sqlite則精簡的多，相對來說，sqlite更像一個access， 是個文件庫的概念，而h2更象一個袖珍版本的oracle或者mysql。。

另外你提到的多進程訪問模式，h2也是可以支持的，設置一個參數即可。

就這一點來說我們是共同的，呵呵

ps一下，你們客服人員到現場連個服務單都不填的，管理那個濫。

如果apusic的技術人員有能力解決，誰還有意見，問題就是。。。。。

呵呵，hp的哪位？ 不要聲張，俺正在做一個科學研究。

我Orz了，作為國內apusic的最早用戶，作為apusic的義務免費測試人員，作為apusic的直接受害者，我今天又Orz了。

ls的，貌似樓主的意思并非是說apusic不能正常使用log4j，而是要自己玩玩。我們使用log4j和在其他應用服務器上并沒有區別。

樓主，你騙點擊也不用這樣么，這跟apusic有鬼關系，你這樣寫只會讓大家以為apusic很濫，雖然她確實很濫，但是作為顧問你要有職業道德么。

呵呵，對日期字段我的原則是允許的情況下，用字符串代替。

寫小方法根本就不是以空間換取時間為目的，而是為了優化代碼的結構和可維護性。

理論上，每個方法的都需要占用內存的一個區間， 方法的調用也會增加性能消耗。有興趣你可以看看inside jvm。 實際上，有些現代編譯器會對某些小方法進行優化做類似inline的操作回避因為方法太多導致的性能問題。

@cracky
謝謝，改了，原來測試有誤

@YODA
改了

@ron

這個，就跟ML一樣，用自己動手才知道爽不爽。
我用的是trac，帶了一個很好的wiki。

@張氏兄弟
源代碼就沒法開源了，這是一個完整的應用項目。 基本實現思路已經寫出來了，熟悉midp和swing的話，重現難度不大。你可以找找ibm的 midp的源代碼看看。
對于手機地圖這種應用，我這套顯然不合適。

@beansoft
呵呵，其實現在企業應用是近期發展的熱點，我也是因為這個才開始做手機應用的，我本來的專長就是企業應用。 現在業務系統的移動化是大趨勢，移動化可以充分激活企業信息流程，那點手機費用對領導來說根本不算什么。只是個人沒有能力拿到政府項目而已。

嗯，暫時還沒法開源，一是因為我現在沒工作，指望看看能否靠這個混點飯吃，找到合作項目或者工作，二是幾個搞移動OA的公司都盯的緊，一開放源代碼，特別是office處理那部分的， 個別惡心公司的陰謀就得逞了。

下半年找到工作解決了吃飯問題再考慮是否繼續做下去了， 那時候會考慮開源的方式做。至于吃國外市場，也有所了解，但是沒有相關資源，而且老外的3g推廣比較普及，應用模式會有差別。