http://www.gbaopan.com/
注冊方便,下載文件也方便.
注冊方便,下載文件也方便.
原文地址:http://www.eclipsezone.com/articles/what-is-iadaptable/
?http://bjzhanghao.cnblogs.com/archive/2005/09/24/243312.html 文章寫的好,翻譯的也好.感謝一下.
j2sdk1.6 不允許多余的byte存在于class文件中。而j2sdk1.5就允許。
??? http://blog.donews.com/limodou/category/35193.aspx
??? ??? 看來要惡補c/c++了要系統的學習一下。limodou ,thank you . ??? 其它資料: ??? Mozilla Xul :http://developer.mozilla.org/cn/docs/XUL ??? ??? ??? ???? http://www.xulplanet.com/tutorials/xultu/ ??? XulPlanet?? :http://www.xulplanet.com/
??? 因為要制作一個安裝程序包,看了Install AnyWhere 和 Install Shield都過于復雜,入門太難。想起以前同事曾用過一個Setup Factory的小工具,現在它已經是7.0了,so cool and beautiful tool.集成了lua腳本語言。
??? lua的table像極了Javascript中的數組。
Programming in Luahttp://www.lua.org/pil/index.html我想我們不必因為lua不是中國人發明的而臉紅,過去的10年本來就不是咱們的,未來的10年也夠嗆。 c語言缺乏lua這種library的支持,最近寫了一個c語言的程序其實關鍵代碼沒有幾行無非是各種數據的轉換如string的操作,dll的調用,可是卻愣是被卡在那里,我得抱怨一下搞c開發的老前輩們了,他們學會了c,使用了c,把c爛在自己的肚子里。沒有想怎樣才能更易于開發和學習。 Lua來了。他們就后悔了。還滿街嚷嚷。
在天庭四年一度的民主生活會上,羊向上帝一把鼻涕一把淚地控訴狼和虎對它們的肆意殘害。上帝很為難,他不能因此就消滅狼或者虎,因為生態要維持平衡,但他再也不能縱容虎和狼這樣下去了。
仁慈的上帝很聰明,他對羊說,你們可以在虎和狼之間任選一頭和你們一起生存,還可以隨時更換他們,剩下的那頭就放在我身邊吧。至少你們能夠減輕一半的負 擔。羊認為狼的胃口比虎小,就選擇了狼。可是狼還跟以前一樣,每天都在追殺羊群。羊群悲憤地請求上帝更換老虎。不料,上帝保管的那頭虎一直沒有吃東西,正 饑餓難耐,它撲進羊群,比前面那頭狼咬得更瘋狂。羊群一天到晚只是逃命,只好把狼和虎不斷更換。可它們同樣兇殘,后來它們索性不換了,讓狼吃得膘肥體壯, 虎則餓得精瘦。眼看那頭虎快要餓死了,羊群才請上帝換一頭。 這頭瘦虎經過長久的饑餓后,慢慢悟出了一個道理:自己雖然兇猛異常,一百只羊都不是對手,可是自己的命運是操縱在羊群手里的。羊群隨時可以把自己送回上帝 那里,讓自己飽受饑餓的煎熬,甚至有餓死的危險。想通這個道理后,瘦虎就對羊群特別客氣,只吃死羊和病羊,凡是健康的羊它都不吃了。羊群喜出望外,有幾只 小羊提議干脆固定要瘦虎,不要那頭肥狼了。一只老羊提醒說:“瘦虎是怕我們送它回上帝那里挨餓,才對我們這么好。萬一肥狼餓死了,我們沒有了選擇的余地, 瘦虎很快就會恢復兇殘的本性的。”眾羊覺得老羊說得有理,為了不讓狼餓死,它們趕緊把它換回來。 原先膘肥體壯的狼,已經餓得只剩下皮包骨頭了,并且也懂得了自己的命運是操縱在羊群手里的道理。為了能在草原上待久一點,它竟百般討好起羊群來,甚至為羊 去挨獵人的子彈,而羊群也把它當作朋友,冒著重重風險把受傷的狼救回來,并為它療傷。等狼康復之后,它們肩并肩地靠在一起跳舞蹈。而那頭被送交給上帝的 虎,見到這一幕時則難過得流下了眼淚。 許多年之后,上帝見到羊牽著狼和虎的手參加民主生活會時,會心地笑了。 只要給羊選擇的權力,它們完全可以過上自由幸福的生活。
? 看到進來大家都在討論“Java將死”特別是Trustno1 的言論,猛然領悟到為什么現在有這么多的FrameWork,或許這些裹腳布就是大廚們的必修功課,可是一旦編譯器來完成這些工作,能夠提供“指那打那的功能”那么“失業青年”也能夠完成現在大廚的工作。
如果Java在下一個版本不提供“支那打那”的功能,那么ruby就會替代Java。OO提供了太多沒有用的功能。 果然JRuby出現了: http://www.javaeye.com/article/24173 http://lightyror.blogspot.com/search/label/jruby 有幸能目睹IT新一門語言的誕生幸甚至哉。 http://jruby.sourceforge.net/
不同classloader加載的class造成isAnnotationPresent失效
@ComponentClass public class Home { } Class clazz = loader.loadClass("Home");??? //loader 和現在運行的classLoader不是相同的。 flag = clazz.isAnnotationPresent(ComponentClass.class);//返回false 原因: Class.clss ?public boolean isAnnotationPresent( ??????? Class<? extends Annotation> annotationClass) { ??????? if (annotationClass == null) ??????????? throw new NullPointerException(); ??????? return getAnnotation(annotationClass) != null;
??? }public <A extends Annotation> A getAnnotation(Class<A> annotationClass) { ??????? if (annotationClass == null) ??????????? throw new NullPointerException(); ??????? initAnnotationsIfNecessary(); ??????? return (A) annotations.get(annotationClass); ??? } private transient Map<Class, Annotation> annotations; 而不同的ClassLoader 加載的ComponentClass不是同一個對象,所以用Class作為id不合適,應該使用String。 解決辦法: ComponentClass.class也使用loader加載這樣才能保證一致性。 banq詳細的解答了這個問題: http://www.jdon.com/jive/article.jsp?forum=91&thread=15456 Classloader存在下面問題: 在一個JVM中可能存在多個ClassLoader,每個ClassLoader擁有自己的 NameSpace。一個ClassLoader只能擁有一個class對象類型的實例,但是不同的ClassLoader可能擁有相同的class對象 實例,這時可能產生致命的問題。如ClassLoaderA,裝載了類A的類型實例A1,而ClassLoaderB,也裝載了類A的對象實例A2。邏輯 上講A1=A2,但是由于A1和A2來自于不同的ClassLoader,它們實際上是完全不同的,如果A中定義了一個靜態變量c,則c在不同的 ClassLoader中的值是不同的。 Thread{ ??? ??? ??? ClassLoader cl = Thread.currentThread().getContextClassLoader(); ??? ??? ??? URL[] urls = ... ??? ??? ??? ClassLoader ncl = new URLClassLoader(urls, cl);//構造新的 ??? ??? ??? Thread.currentThread().setContextClassLoader(ncl); ??? ??? ??? do do do do; ??? ??? ??? Thread.currentThread().setContextClassLoader(cl);//執行完恢復 }
http://liumspace.spaces.live.com/blog/cns!bc24129fc2e42afd!122.entry
JavaXPCOMJavaXPCOM基于一套與Eclipse SWT不同的思路。在JavaXPCOM中,每一個XPCOM interface有一個對應的Java interface,注意這里是Java interface,而不是Java class。那么,在JavaXPCOM中怎么生成一個XPCOM對象的Java wrapper呢?在JavaXPCOM中,巧妙地使用了reflection。對每一個XPCOM對象,會生成一個Proxy 來作為Java wrapper,這個Proxy對象實現XPCOM對象所實現的interface。然后這個Proxy把Java interface中的方法調用再delegate到一個JavaXPCOM提供的XPCOMJavaProxy(實現InvocationHandler)上。這 里有幾個問題:1。系統根據一個XPCOM對象的指針,怎么知道這個XPCOM對象實現了什么XPCOM接口?再怎么根據這個XPCOM接口找到對應的 Java interface來生成Proxy?2。XPCOMJavaProxy怎么把一個Java調用再映射到底層的XPCOM調用上? JavaXPCOM是這樣實現的:
在Java中實現COM/XPCOM組件(component)前面討論了怎么從Java中調用COM/XPCOM中的組件,接下來討論怎么用Java語言來實現COM/XPCOM組件。 JavaXPCOM?JavaXPCOM中的支持還是依賴了type
information,這是有了這個依賴,JavaXPCOM中實現XPCOM組件要容易得多。在JavaXPCOM中,只需要這個Java對象實現了
所需要實現的XPCOM interface所對應的Java interface即可。
JavaXPCOM優點:
1.該來的終究會來,出來混,總是要還的。
什么都不懂,也許過得還會快樂些,無須天天學習。:-) 2.思路和產品都是好的,但是只能運行在windows上的東西,難成氣候。微軟借鑒了很多開源社區的成果,開源社區也會學習,超越微軟。 就像myan自己說的微軟犯了戰略錯誤,戰略錯誤不僅在斷了adobe的生意,更重要的是把自己囚禁在獨立王國里,就像唐朝以后的中國,依舊輝煌,依舊領先,卻不屬于世界。 微軟老了。 3. 以開發者的視角看,這項技術的確讓人激動。
以用戶的視角看,這要求:
* 我們安裝WPF的runtime * 以微軟一貫的伎倆,這個runtime最多向前支持到XP,而2000之類將被拋棄 * Vista內置runtime,不過從XP 2001年推出到現在,仍是2000和XP對分天下的局面來看,Vista的用戶基數增長不是很樂觀 * 最核心的問題是:WPF這項技術提高用戶體驗、提高系統交互性能否超越HTML+CSS+AJAX還是個問題,說實在的優秀的CUI(Console UI)程序的交互性比GUI程序的交互性強了去了。 結論:5年后我們再看,不過五年后變數仍是未定。 Google現在是致力于打造自己的超級計算服務器端,MS從一種邪惡的角度來收攏對開放者的控制權,一個內修,吸引用戶,一個外張,控制開發者,鹿死誰手,再看吧…… 總之,現在越來越不喜歡MS,強迫大家升級硬件和操作系統,硬件升級帶來的好處都被操作系統占了便宜,CPU和內存都被OS用了去,這樣用來解決用戶問題的資源就少了,邪惡阿!! 4. 誠然,從純技術的角度來看,我們也早就認為XUL/XAML一類使用XML來描述界面組件和布局的技術肯定是Web界面開發技術的發展趨勢。W3C今年成 立了一個工作組,希望將XUL、XAML、MXML等幾種界面描述語言統一為一種標準的格式(http: //www.w3.org/2006/appformats/)。所以我們認為孟巖老師所看到的趨勢是沒有大問題的。從純技術的角度來看,將來的Web界 面開發肯定會發展到這種技術。 ? 5.軟件開發并不是流水線式生產。分工應該適當,分工太細,不同層次之間溝通的成本就會迅速上升。這又回到了 《人月神話》中的命題:主要的成本在于溝通的成本。依靠細致的分工降低對開發人員素質的要求,實現流水線式生產,創造大批軟件藍領,這本身就是一個幻想。 Ruby解決問題的思路與此是不同的,Ruby的思路是提高抽象的層次,使得一個開發人員有能力承擔更多功能的開發。 總結了以上眾人之言,我想說的是: ??? 當以開發人員為本,得開發人員者得天下。 另: http://www-128.ibm.com/developerworks/cn/linux/l-enhydra/index.html 2.1.2 一流的表示技術 XMLC的簡潔和強悍,奠定了它在表示技術中的領先地位。
引自: http://ajaxcn.org/forum/posts/list/304.page |