Picses' sky

據說核心api也不是一樣的，jfc本身是一個一棧式的api庫，底層基于的jni是固有的，android并不是從底層照搬這種類層次結構，但Harmony作為遵循java標準的虛擬機實現必須提供標準的api實現，所以android從api級別也不是java程序員可以容易過渡來使用的，基本上說，android只是借鑒了java的語法和一些api接口樣式，本質上是完全不同的語言平臺。
另外，樓主寫得實在有點言過其實了，google的android面向的是手機平臺，追求的是自由和創新，那它在未來必然也會因為java語法上的對底層不友好而采用和.net同樣的方式——指針，然而基于Harmony的實現應該不支持這樣的做法，到最后，Dalvik必然會脫出Harmony的束縛，成為徹頭徹尾的另一個.net, android有點掛羊頭賣狗肉，它影響不了java。

下來看看。

呵呵，支持。
有時候會頓一下，是解碼器的問題還是gc調用引起的？

ruby了解下，d語言也了解下，關心一下編程未來的走勢。

2歌詞目錄最好做成可指定的，方便很多
3標簽修改可以兩種做法，一種是你播放歌曲本身就是一個緩存的文件，而不是真的文件，第二種就是等到下一首歌再把當前的標簽實際修改進文件，而立即生效的是播放列表的顯示而已。

受教了。

高效的開發，良好的架構，KISS的哲學，也是java比其他語言更多關注的東西，畢竟你不如人家快，但語言本身的優雅和靈活使你在這方面能比其他語言更容易提升，最后才是效率考慮和優化，當然，這有一個大前提，那就是功能架構的時候你就想清楚了正確的方向，因為大的方向上是正確的，所以可以不用過早的優化。

最后的這個方法：
private static String getBB() {
return "b";
}
如果加上final應該會內聯吧，說不定還是可以的哦。

佩服,用debug應該很能說明問題拉.

很有道理，設計確實不是一蹴而就的，只要遵循了好的模式和思想，體系就自然能夠解離和擴展。

確實很強大，可以方便地做成電子書或導出成網頁，不過一直沒找到好的破解，用起來有時會在頁面邊角留下未注冊的文字。

既然提到了代碼拖拽，那我也提一下代碼復制和文件復制，eclipse從3.2之前就實現了這兩點，而netbeans直到6才有文件復制。
代碼復制就是你剪貼板中有一份完整的java源文件的文本(注意是文本，不是文件)，點選一個包ctrl v，就可以自動生成基于此拷貝文件名的java源文件，文件拷貝類似，也就是說你可以從netbeans中拷一個java源文件的文本粘貼到eclipse中并生成一個獨立的java源文件，卻不能作相反的操作，因為netbeans還不支持，從網上拷代碼下來運行的人就知道這個功能有多劃算了。
代碼拖拽只是小功能，就如同refactor盡管不是小功能，但讓它在后臺自己運行同樣只是小功能一樣。
上面還提到jfiledialog，那是基于awt的，和使用swt的filedialog有什么區別，jfiledialog不能設置多個filter，功能比起swt也太過有限，swing優勢在于仿生，所以jfiledialog可以作為項目中的替代方案，但拙劣的很。
eclipse還有個功能是大范圍organize import，最大是基于所有包的，netbeans rc1仍未實現，且refactor中的包重命名，尚不支持subpackage，速度也很慢，猜想還在完善中，所以，netbeans要走的路其實還很遠，是好是壞還是拭目以待吧。

ria可以為bs，cs通用，可以說是將來基于mvc實現的所有項目（不論大小）的表現層，基于不同程度實現的view多數已經接近跨平臺的水平了，再加上炫麗的外觀確實提高了交互，盡管我也同樣對目前已知的ria質疑，卻不得不說只要瀏覽器還沒有過時，ria就還在壯大，等到瀏覽器過時了，ria就走得更遠了。

android是指手機操作系統吧，當然系統里包括了google的java vm，核心api等，獨立的實現，所以應該把這里的.dex當作gphone的專有語言程序了，它不是走跨平臺的路線，只想自己用把。

確實發布了，首頁上都給出圖片鏈接了。試用感覺速度又提高了點，贊。

是啊，TreeCellRenderer提供組件只用來實現節點本身的繪制，但節點所占的空間大小卻不知用什么設置，我試過tree的getPathBounds()方法，好像也不是，哎。

有個問題請教樓主，如何實現jtree針對不同節點的組件有不同的行高度，我現在被這個問題困擾了很久，想用拖拽來改變節點的行高，在DefaultTreeCellRenderer里處理重繪出來，但是在里面用setSize()怎么改都不行，網上沒搜到這樣的例子。

樓主真勤勞，趕緊去下載了。

樓上說的那本書好嗎？講哪方面的東西啊？
全局變量有時也會用到的，jvm很多借助類的靜態的東西，那就是全局的了，否則很多實例引用在對象間傳遞起來過于復雜了。

看來大家都去看九宮格了，不錯。
樓主的文章應該讓搞界面的人都看看。

finalize和釋放資源有關，但你說和析構有關確實容易讓人想反駁，因為finalize并不是像析構函數那樣讓人手動調用的，功能和使用方式都沒用相似的地方。
第5條沒看懂什么意思，還有16說“C++ 中有運算符重載 , Java 里只有 + 號有重載的意思，不過在 JDK5 中也有其他的運算符重載，比如兩個類對象可以直接相加”，還真沒聽說過有這回事，相加不就是用+，哪來其他的運算符。
泛型加入后可以說是充斥jfc，這是不可撤銷的，所以sun很慎重，泛型真用起來完全讓人摸不著頭腦，我沒用過模板，但c++實現一定更難于使用，我想表達的意思是，泛型讓很多人覺得java難了，繁瑣了，這本是選擇java而非c++的理由，靠負責好面面俱到并不能讓java更好用。

確實bug很多，beta2也是，升級了的swing app framework版本基本可以看得出輪廓了。但可視化界面操作是雙刃劍，也可能會影響開發，我也喜歡swt，最喜歡的是eclipse的rcp，很好的框架，不知netbeans這方面做得好不好，ibm是很了不起的公司，看它提供的控件，提供的milestone的說明，感覺是很專業很為開發者負責任的在做產品。sun要多學點啊。

阿門，我這一輩子啊，還是趕緊轉行得了，考公務員和考研的準備不能間斷啊。當講師需要資歷和條件，一般都是干程序員干出點成績來了才行。

老是想到有個什么東西可以，原來是Tracker，swt sample里有。還有就是swing實現透明窗格，最近才知道還有個jna，看這里：http://www.aygfsteel.com/ruislan/archive/2007/10/24/154689.html
只是不知是否可以跨平臺了，我以前一直覺得只要能有透明窗格，swing也能有Tracker這樣的東西了，現在又不確定了，因為透明ms上面的一切都變透明了，不知畫出來的線還看不看得到，不然就只有用toolkit里的取capture的方法模擬桌面來實現。
還有個問題，為什么我以前裝ubuntu的時候java不提供win L&F，在win下也不提供GTK L&F，如果是許可證的問題那我們以后要怎么用它的皮膚啊。

看樓主的文章，一時豁然開朗，gui原來可以是這樣的，以前也下載過很多軟件，最近才慢慢開始注意界面布局的特點和提供用戶體驗方面的東西，感覺歐美軟件逐漸在界面上追求簡單和易用，ComponentListener的思想有時比布局管理器容易和適合開發的需要。
樓主提到Java已經可以在桌面應用領域挑戰C/C++,VB,Delphi等等，但是這類工具生成的是編譯型的機器代碼，具有高的執行效率和借助平臺特有優勢，盡管Java跨平臺，又有JIT即時解釋器在一定程度上提升運行速率，但是否語言級別和平臺級別的一些瓶頸會成為它開發上的局限性呢，比如，我現在涉及對數據的壓縮解壓和即時取用，要求高響應的速度，我想可能的突破是好的算法實現，而這一層面上對數據結構的要求相對獨特——針對位的操作，而Java的基本數據類型中，幾乎是基于字節的，boolean在底層數據實現上也不例外（希望我沒理解錯），這在實現很多算法上并不理想，不知樓主的意見如何？
說到swt，我也先學了點swing再來學的，如果有說的不對的請指出，除了無法獲得jdk的標準集成支持外，swt可以說在各個方面都勝過awt，之所以說awt是因為二者的實現是相似的對等體思路，swt在這方面作得很好了，那可以假設swt和awt在速度上是同一級別的東西，如果IBM現在搞基于swt基礎之上的純繪制桌面應用，就相當于在swing的同一級別之上，這方面IBM沾上邊的象GEF,Draw2D可能有點聯系吧，它有可能作到類似swing的程度和規模嗎？就算不行差一點，但保持相同的速度級別我想還是有很大作用的，比較一下：awt是弱的，但基于其之上的swing是繪制一切無所不能的；swt是強的，而在其之上作為補充的純繪制api也能成為其補充，在我看swt的介紹時看到這一句，對平臺缺失的組件用Java繪制，這種繪制指的其實是用平臺已有的swt組件進行組合獲得復合控件，我看過eclipse Nebular項目，主要的自定義控件思想也是這樣的，它一方面基于高效的本地控件來復合，同時也可能引入本地控件的問題。但是就現階段來說，sun對swing的支持還未全面鋪開到最關系用戶切身體驗的范圍，舉我上次評論說過的JFileChooser，速度和awt是秒和毫秒的差距，當然，這是可以通過編程手段來忽悠用戶的，比如開個線程，在打開的第一時間在后臺創建備用，就比如jdk demo中的swingset2的方式，但是，這比較讓人難以接受，我只為了提供一個讓用戶選擇路徑的控件，用完就扔掉的東西，卻不得不忍受全繪制界面帶來的時間延遲，真的很不值得。
寫到這里，只感覺腦袋空空，好像成不了文章了，只是還是想和大家分享，希望有人能討論，希望想法沒有浪費。

第一副圖標簽頁下有橫線，是viewpart沒設焦點的原因。

兩個功能都是依賴java5來實現吧。

java的浮點數據類型幾乎毫無精度性可言，只能適應于近似計算，這倒不一定和芯片有關吧，你可以上網看看，看過之后估計對浮點數一點信心都沒有了。
java線程實現是基于平臺特點的沒錯，但同樣可以保證跨平臺的線程設計準確可靠地運行（前提是你設計得對），畢竟多核模擬出的是和單核相似的不確定性的線程執行情況，而確定性的編程設計才是基于這個之上的。

jvm是在底層用os實現thread的，所以線程問題在java中反而容易呈現因平臺而異的現象，java能不能充分利用雙核的硬件資源，是看對應的操作系統的實現的。
搶占和時間片，可以同時作為調度策略，所謂搶占，也不是優先執行，根據實現不同，可以是時間片加長，或者輪替幾率加大。

我截了圖
http://www.aygfsteel.com/Files/djsl6071/桌面.rar
第一張是正常情況，第2，3張分別顯示向上、下拖動時出現的缺失。
你可以用windows自帶的圖片查看器打開，并放大，仔細看虛擬滑塊的邊緣。

進一步觀察發現，lz的代碼運行時虛擬滑塊的邊緣往往缺失，結合上一條評論談到的，我想移動滑塊時重

繪的是移動操作的上一次tempLocation指出的舊滑塊的區域，而我們想要看到的新滑塊的區域，并沒有全部被納入重畫的范圍，修改的方法：
redraw(tempLocation, 0, TEMP_H.getBounds().width,TEMP_H.getBounds().height, false);
tempLocation = valueToPels(getValue()) + movedX - TEMP_H.getBounds().width / 2;
redraw(tempLocation, 0, TEMP_H.getBounds().width,TEMP_H.getBounds().height, false);
還沒想到更好的方法。

redraw(tempLocation, 0, TEMP_H.getBounds().width,TEMP_H.getBounds().height, false);
是只重繪temp thumb原來的區域，因為slider本身添加自己為PaintListener，故重畫的時候paintControl被調用，那么paintControl方法作用的是整個圖形區域還是temp thumb原來的區域？如果是后者，那新的temp thumb所在的區域由誰在何時繪制？ 如果是前者，重繪的不還是整體而不是thumb的區域嗎？

Swing是Java平臺的標準桌面實現，awt的早期的成型為Java技術在桌面的發展奠定了堅實的基礎，最底層的實現顯然是對等體來鋪墊的，往上走產生了兩種不同的思路，Swing和SWT，他們生來都是為了一個目的，讓Java更好用，更多人用，Swing是了不起的框架，經典的設計，復雜而靈活，SWT晚出生一點，它是看著Swing的不足在發展自己的，它一出生并沒有想過和Swing爭，所以只是從實際的產品除非，滿足實際的需要，只是eclipse用得好了自然而然的想到借鑒它成功的因素，才想著復用自己的那一套，所以它一出生，就烙著便利軟件產品的特點，即便是到了如今，JFace出來了，RCP出來了，哪一個不都是走在Swing前面，Swing開源的api也是有不少的，Application級的全棧式框架也不是沒人做過，為什么sun從來都沒有加入過JFC中，直到今天，Netbeans來了，帶來了這一些，但還是沒趕上SWT的，用過JFace的人都知道，IBM在其中開發了多少成熟的組件，Preference，Wizard，一個個很簡單，卻是現代軟件產品中已經上升到了經典范疇的概念，Swing的api中有嗎？還要復用多少次才會被加進去呢？
SWT的gc，它同樣可以繪制一切，那它的速度不會比Swing快多少吧？Swing中有象SWT中的FileDialog那樣借助操作系統實現的組件嗎？我用過JFileChooser，速度比FileDialog起碼慢5倍，創建完了不能釋放，以便下次打開保持較快的速度，這期間占用了多少內存？跨越的基本是整個產品的生命周期，實際項目中，一個JFileChooser，足夠否決Swing的理由了，何況象JFileChooser一樣慢的，有多少個。SWT的一大弊端是jni，本地方法調用的時間消耗和內存管理成本會在運行時和編程上產生不利的影響，特別涉及純Java對象在本地組件上的呈現，會是很大的問題，暫時并沒有好的解決方法，主要是繞過，缺失某些極具表現力的界面效果，而一板一眼，中規中矩。
Swing沒有錯，錯的是它身后的SUN，SWT并不是最好的，但它得益于IBM。從今天開始追來得及嗎？除非你讓我在Swing中用FileDialog，既然我已經可以多少用些SWT_AWT了。

從誕生以來，Java一直被認為是一個擁有面向對象的高級語言特性并擁有健壯穩定運行平臺的技術，它作為語言和平臺的雙重身份而被程序員所接受，編寫富于編程思想和設計模式體系的軟件產品。
它的優點是虛擬機，使其輕易實現了跨平臺，強大的垃圾回收和相當純粹的面向對象編程法則，這些都是上層建筑，而在底層支持的，是一個仿真的機器，字節碼的解讀是以jvm的指令序列的方式，在底層，拋開了所有高級語言的特性，那就是接近匯編級別的指令。這樣的層次結構，不僅有利于跨平臺的實現，更有利于語言技術的自適應發展，隨時調整自身的語法和結構，與時俱進。

你可以使用接口作為一種行為的協議，它可以實現自繼承層次中的任何類（也就是它可以是任何派系）。
1.在沒有關聯的類之間保留相似性而不依賴類的(繼承)關系。
2.聲明多個類(它們多半是平行的，沒有繼承關系)中期望實現的方法。
3.展現一個對象的編程接口而不是它的類。(面向接口編程，ruby中的duck type的思想解釋得很形象)
3.建立多繼承模型，一種在一些oo語言中允許的一個類有多個父類的特性。

報告一個問題，本人用的是jre1.6.0_0.3，exe4j有個功能是搜索指定目錄的jre，這個功能有個bug，如果你用剛重裝windows的還沒有裝任何軟件的操作系統測試，盡管目錄中包含的jre的版本，exe仍會報錯，提示缺少msvcr71.dll(這個文件其實在jre\bin下)，解決辦法是把它放在exe的同一目錄下，或者用exe4j中可以指定本地庫的功能，在其中指定jre\bin為一個本地庫，那個dll并非jvm所特有，所以可能有些人裝了visual studio之類的默認會裝一個到系統中去，所以看不出問題，希望lz驗證一下，如果沒問題的話補在你的文章的后面提醒大家。

lz很強啊，難道swing和swt通吃？

我最早是用textpad，eclipse的語法解析和內容助手是相當強大的，據說只有idea更強一點，netbeans和它同屬開源產品，java世界里一般都能找到2個以上競爭性的且都不錯的產品，有福了大家。

個人覺得如果從頭學起，特別是jvm指令基礎，可以配合學一下ant(moven則是ant將來可能的替代，好比svn和cvs)。類名方法名的記憶并不是必須的，可以“懶加載”。

@Raylong
不是的，java的數組就是對象，對象任何時候都是在堆中存儲，像你說的“如果沒有引用能到達{1,2,3}它會銷毀的，如果int[] a = {1,2,3}; 包含在方法中，你說的沒錯。”前半句是沒錯，如果沒有任何引用確實會銷毀，a引用如果再賦值給其他變量(可能是全局的)，那么這個數組不會被銷毀，讓它在棧中存放是沒有意義，如果這種情況大量出現明顯影響jvm的使用，sun不會留下讓程序員犯錯誤的機會。

swt就是jni實現的，所以它dispose的時候一定就釋放了系統的資源(除非swt可能有的bug)，留下純java的對象卻是gc管理的，所以你確定dispose了的話問題就還在jvm內部，大的數據量一般會有緩沖機制，說到這里，不知你的程序是否依托于容器了，提供了對象緩沖池的實現，需要時獲得對象，釋放時直接歸到池中，不作銷毀，而是供下一次類似的請求直接修改并做二次使用，通過動態調整對象數量來適應不同需求。(但也可能內存占用增加就時由這部分的不合理使用產生的，看看容器有沒有全局變量的使用，例如session之類的)

你上一篇中提到任務管理器顯示占用增加，我覺得并不是程序在占用，而是虛擬機根據你程序使用內存的趨勢不斷要求系統提供更大的內存以保證程序的運行。

還有swt占用的系統資源不會由jvm管理，所以你對swt資源的釋放對jvm內存占用沒有影響。

給我一份吧
djsl6073@126.com

我也要一個，謝謝了先
djsl6073@126.com

@千里冰封
其實無論jdic，還是java6里采用的方式，抑或swt，本質都是jni的方式去解決這一問題，然后跨平臺實現了。比起swt，swing才是真正的龐大，當然這也體現了它功能的強大以及速度的相對延遲，說道gui開發的首選，如果項目設計了和本地操作系統相關的，就好比這個瀏覽器，完全可以用swt了，畢竟它多少還是有跨平臺支持的。

樓上說的在理，原帖是4年前的吧，那時java方興未艾，完全oo的想法正流行，大家對oo也都還帶有不同程度的誤解，而今再回首，也許都看得開了。

以前也用相似的方法寫過一些其它的東西，比如可以自由拖動并顯示背景的半透明窗口啦，放大鏡啦，結果都以失敗告終了，主要是無法隨背景的更新而更新，能夠更新的又無法保證效率，樓主有沒有興趣嘗試一下。

看冰封說的，swt還是不錯的，老實說覺得用swt和用vb之類的差不多，簡單點，追求速度，用戶滿意度，但由于并非由jvm控制資源，很難獲得穩定性。swing的架構那是經典mvc，在配以jvm的呵護，自然是優秀的，簡直是媲美j2ee的架構啊。

聽說java中時間的操作有一些不是很精確，不清楚具體指哪一塊，樓主有沒有研究呢，感覺用calander會好點.

UI delegate 是swing在mvc基礎上加的一些提高靈活性的擴展，外觀同樣是隨操作系統本地的外觀呈現的，awt只是swing最底層的基礎，老實說這個基礎薄弱而且過于依賴平臺對等體，swing就好像借awt這只雞生的蛋，用的只是那個殼，而繪制了其他的一切來確保了幾乎沒有平臺差異，可能用慣了swt的對awt不會怎么反感，但是用慣了swing的卻不會想去用awt。
覺得setUI的方法確實比在button上編碼修改好，起碼可以動態裝卸。其實swing只對平臺共有的個性化組件使用了UI delegate，自然是認為這些組件才被用戶視為理當呈現為平臺上的樣子，而如樓主的這個例子，使得任何平臺和任何laf下按鈕都會是同一個樣子，談不上有什么問題，這個看項目的需要。
swing是個不錯的平臺差異化下桌面解決方法。

個人也覺得oo中會出現一些問題,這些問題隨著技術和思想的進步日漸凸現.

但就本文的觀點,其實談不上是oo的封裝和繼承帶來的,很多往往是我們設計人員的疏忽.

比如第一個stack的例子,ArrayList是明顯的jfc,繼承自它是完全沒有必要的,除非你的類在抽象空間中能夠真正代表ArrayList類的一個特殊子類集合,面向對象優先考慮抽象空間的完美而不是效率和實現空間的簡便,這是規則,也是出于ood的要求,在這個實例中,明顯應該用聚合而不是繼承.

拋出異常的問題,對不支持的方法拋出異常過于拙劣了,完全可以在繼承樹的層次上加上抽象類,很好地分叉,而不是依賴有限的異常處理機制,異常處理在面向對象構架中算得上相當游離的一個功能了,盡管看似也有類的繼承關系,但獨立的捕獲和處理,并不適合作為業務邏輯的相關環節實現.

oo的問題個人覺得很多在繼承層次的復雜性，jfc庫繼承層次過多，導致無法查知當前方法的具體調用棧位置——也就是具體方法的實現方式往往被復雜和繁冗的繼承和封裝掩蓋，讓人摸不找頭腦，不知道過程邏輯究竟在何處實現，也就無法最大限度地學習已有的類庫（當然，只是學習和修改，因為使用是不需要知道了，畢竟封裝就是為了屏蔽實現細節。）