9910

单飞

   :: 首页 :: 联系 :: 聚合  :: 管理

#

http://www.gbaopan.com/
注册方便,下载文件也方便.
posted @ 2007-03-19 17:01 单飞 阅读(264) | 评论 (0)编辑 收藏

原文地址:http://www.eclipsezone.com/articles/what-is-iadaptable/

 http://bjzhanghao.cnblogs.com/archive/2005/09/24/243312.html

文章写的好,翻译的也好.感谢一下.


posted @ 2007-03-16 08:14 单飞 阅读(227) | 评论 (0)编辑 收藏

j2sdk1.6 不允许多余的byte存在于class文件中。而j2sdk1.5就允许。
posted @ 2007-02-28 11:24 单飞 阅读(752) | 评论 (0)编辑 收藏

    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/
posted @ 2007-02-13 09:22 单飞 阅读(160) | 评论 (0)编辑 收藏

    因为要制作一个安装程序包,看了Install AnyWhere 和 Install Shield都过于复杂,入门太难。想起以前同事曾用过一个Setup Factory的小工具,现在它已经是7.0了,so cool and beautiful tool.集成了lua脚本语言。
    lua的table像极了Javascript中的数组。

Programming in Lua

http://www.lua.org/pil/index.html

我想我们不必因为lua不是中国人发明的而脸红,过去的10年本来就不是咱们的,未来的10年也够呛。
c语言缺乏lua这种library的支持,最近写了一个c语言的程序其实关键代码没有几行无非是各种数据的转换如string的操作,dll的调用,可是却愣是被卡在那里,我得抱怨一下搞c开发的老前辈们了,他们学会了c,使用了c,把c烂在自己的肚子里。没有想怎样才能更易于开发和学习。
Lua来了。他们就后悔了。还满街嚷嚷。

posted @ 2007-01-18 16:48 单飞 阅读(552) | 评论 (0)编辑 收藏

在天庭四年一度的民主生活会上,羊向上帝一把鼻涕一把泪地控诉狼和虎对它们的肆意残害。上帝很为难,他不能因此就消灭狼或者虎,因为生态要维持平衡,但他再也不能纵容虎和狼这样下去了。

仁慈的上帝很聪明,他对羊说,你们可以在虎和狼之间任选一头和你们一起生存,还可以随时更换他们,剩下的那头就放在我身边吧。至少你们能够减轻一半的负 担。羊认为狼的胃口比虎小,就选择了狼。可是狼还跟以前一样,每天都在追杀羊群。羊群悲愤地请求上帝更换老虎。不料,上帝保管的那头虎一直没有吃东西,正 饥饿难耐,它扑进羊群,比前面那头狼咬得更疯狂。羊群一天到晚只是逃命,只好把狼和虎不断更换。可它们同样凶残,后来它们索性不换了,让狼吃得膘肥体壮, 虎则饿得精瘦。眼看那头虎快要饿死了,羊群才请上帝换一头。

这头瘦虎经过长久的饥饿后,慢慢悟出了一个道理:自己虽然凶猛异常,一百只羊都不是对手,可是自己的命运是操纵在羊群手里的。羊群随时可以把自己送回上帝 那里,让自己饱受饥饿的煎熬,甚至有饿死的危险。想通这个道理后,瘦虎就对羊群特别客气,只吃死羊和病羊,凡是健康的羊它都不吃了。羊群喜出望外,有几只 小羊提议干脆固定要瘦虎,不要那头肥狼了。一只老羊提醒说:“瘦虎是怕我们送它回上帝那里挨饿,才对我们这么好。万一肥狼饿死了,我们没有了选择的余地, 瘦虎很快就会恢复凶残的本性的。”众羊觉得老羊说得有理,为了不让狼饿死,它们赶紧把它换回来。

原先膘肥体壮的狼,已经饿得只剩下皮包骨头了,并且也懂得了自己的命运是操纵在羊群手里的道理。为了能在草原上待久一点,它竟百般讨好起羊群来,甚至为羊 去挨猎人的子弹,而羊群也把它当作朋友,冒着重重风险把受伤的狼救回来,并为它疗伤。等狼康复之后,它们肩并肩地靠在一起跳舞蹈。而那头被送交给上帝的 虎,见到这一幕时则难过得流下了眼泪。

许多年之后,上帝见到羊牵着狼和虎的手参加民主生活会时,会心地笑了。

只要给羊选择的权力,它们完全可以过上自由幸福的生活。
posted @ 2007-01-07 18:55 单飞 阅读(254) | 评论 (0)编辑 收藏

  看到进来大家都在讨论“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/
posted @ 2006-12-27 17:18 单飞 阅读(243) | 评论 (0)编辑 收藏

不同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);//执行完恢复
}
posted @ 2006-12-20 20:35 单飞 阅读(478) | 评论 (0)编辑 收藏

http://liumspace.spaces.live.com/blog/cns!bc24129fc2e42afd!122.entry

JavaXPCOM

JavaXPCOM基于一套与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是这样实现的:
  1. 对每一个XPCOM对象的指针,知道其实现的interface的IID。
  2. 使用nsIInterfaceInfoManager来reflect 这个IID,得到这个interface的meta data(nsIInterfaceInfo
  3. 将这个XPCOM对象的指针及nsIInterfaceInfo组合在一起,放在一个JavaXPCOMInterface的数据结构里。
  4. 用这个JavaXPCOMInterface结构的指针来构建XPCOMJavaProxy(java wrapper)。构建XPCOMJavaProxy对象时(XPCOMJavaProxy#createProxy(Class aInterface, long aXPCOMInterface))有两个参数,第一个为这个proxy实现的Java interface。这个Java interface的名字由"org.mozilla.xpcom" + (XPCOM interface name)得来。
  5. 当XPCOMJavaProxy上的方法被调用时,native code会得到方法名、参数数组以及JavaXPCOMInterface的指针。从JavaXPCOMInterface可以得到 nsIInterfaceInfo,通过nsIInterface里所包含的meta data,可以得到这个方法在virtual table中的位置。同时meta data还会包含信息说明每个参数的数据类型,根据这个信息,可以把每个参数marshall成一个nsXPTCVariant结构。
  6. 通过xptcall,就可以完成对virtual table中的方法的调用。
  7. 对方法调用的结果,可以再根据meta data来unmarshall成Java对象。如果某个out参数或return参数是一个XPCOM对象,在meta data中会描述这个参数的interface的IID,那么又可以象第一步一样来对其生成Java wrapper(XPCOMJavaProxy)(nsJavaXPCOMBindingUtils.cpp#GetNewOrUsedJavaObject)。
当然,实际的实现更复杂,比如说有一个global table来记录Java wrapper与native的JavaXPCOMInterface之间的关系以避免不必要的多次为同一XPCOM对象建立Java wrapper等。

在Java中实现COM/XPCOM组件(component)

前面讨论了怎么从Java中调用COM/XPCOM中的组件,接下来讨论怎么用Java语言来实现COM/XPCOM组件。


JavaXPCOM

 JavaXPCOM中的支持还是依赖了type information,这是有了这个依赖,JavaXPCOM中实现XPCOM组件要容易得多。在JavaXPCOM中,只需要这个Java对象实现了 所需要实现的XPCOM interface所对应的Java interface即可。
  1. 当一个Java object作为参数传给某个XPCOM方法时,native code会通过这个方法的meta data,知道这个参数应该是一个XPCOM对象。
  2. native code会检查这个Java object是不是一个Java wrapper,如果是,那么可以直接从这个Java wrapper知道它所wrap的XPCOM对象。
  3. 接下来会检查是不是已经给这个Java object生成过stub,如果没有则生成一个nsJavaXPTCStub。nsJavaXPTCStub 会根据meta data生成virtual table,而且当virtual table中的方法被调用时,会根据meta data知道被调用方法的名字,再根据这个名字到Java object中通过reflect找到对应的Java方法并调用它。
另外JavaXPCOM的实现中还实现了reference management,这样在Java code中不再需要去实现如AddRef/Release,系统已经都管理好了。


JavaXPCOM

优点:
  1. 每个XPCOM interface对应到Java中还是interface。
  2. 支持Java的garbase collection。在XPCOMJavaProxy中,重载了finalize()方法,所以Java programmer不需要再去调用Release。
  3. 增加新的XPCOM interface容易。只需在org.mozilla.xpcom这个package中增加相应的Java interface即可。
  4. Java interface可以通过工具自动生成。
  5. 用Java实现XPCOM组件非常简单。
缺点:
  1. 由于实现依赖nsIInterfaceInfoManager,也就依赖typelib。这样一来,方法调用不能象Eclipse SWT中一样直接转换为virtual table调用,效率要明显低一些。另外,只能支持那些支持typelib的interface。
  2. 虽然增加新的XPCOM interface容易,但这个interface必须放在org.mozilla.xpcom这个package中,不适合第三方扩充。




posted @ 2006-12-04 17:19 单飞 阅读(1198) | 评论 (0)编辑 收藏

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的简洁和强悍,奠定了它在表示技术中的领先地位。

  • 使用Enhdyra XMLC,界面设计人员和后台程序开发人员可以很好地分工协作。界面设计人员几乎可以任意修改用户界面而不会影响后台程序开发人员,反之亦然。
  • 使用Enhydra XMLC,界面设计人员和后台程序开发人员只需要在项目开始时一起商定需要动态修改的元素及其ID值,其后就几乎不需要相互碰头了,分头去实现就可以。
  • 使用Enhydra XMLC,界面设计人员不需要任何的Java知识,只需要专注于界面设计即可。
  • 使用Enhydra XMLC,后台程序人员只需要极少的HTML等标记语言知识,只需要专注于动态内容的显示控制和业务流程的设计即可。
  • 使用Enhydra XMLC,可以使用任何你熟悉的HTML编辑软件,因为XMLC没有引入任何额外的标记元素。Enhydra XMLC中所重用的ID元素,是HTML 4.0及其以上版本的标准元素。
  • Enhydra XMLC把页面(HTML,XML,WML等)转换有对等的Java类(DOM树),就意味着可以从面向对象的角度来操纵整个页面。
  • 使用Enhydra XMLC,使得同时支持WML,XHTML,cHTML/i-mode,voiceXML,J2ME变的非常简单。

引自:
http://ajaxcn.org/forum/posts/list/304.page

posted @ 2006-12-02 21:30 单飞 阅读(387) | 评论 (0)编辑 收藏

仅列出标题
共12页: First 上一页 4 5 6 7 8 9 10 11 12 下一页