马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
先说优点,首先和C,C++这些语言比起来,java很简单,去掉指针的java,非常好理解,自动垃圾回收机制也很好,自从JDK1.5推出以后,性能上又有了很大提高。上个月的一篇旧事谈及了JSR277和OSGi(即JSR291)的情况,这在JSR277专家组邮件列表中激发了一场剧烈的争辩,这场争辩是往年以来最为剧烈的一场。这以后的次要推进者之一就是BryanAtsatt,他是JSR277(模块)和JSR294(超等包)的专家构成员。他说JSR277能够赛过OSGi: 初始标准实践上包括两个自力的部分:一个api/框架,一个带有新的分发格局的完成。不幸的是,人们老是不加区分地先容他们。更遭的是,新的分发格局(“.jam”文件)常常占有下风。
那末JSR277怎样赛过OSGi呢?经由过程向SE情况供应严密的集成。其上风次要表现在以下四个方面:
- 正则存储模子
- 编译期依附的决意
- 跨模块完成的类/资本共享
- 经由过程命令行的实行
关于现存的OSGi包来讲这些都可行。还能更好点吗,哼?大概另有但愿。 现实上,Bryan已在JSR277专家组中宣布了大批的批评;他提出标准应当与完成相分别,由于在专家组的草案先容中它们已搅浑在一同了;别的他又提出PeterKriens应当到场出去:专家组已深陷泥潭了,我们必要从头步进正轨。我提出以下详细步骤:
- 让PeterKriens到场到专家组中。Peter在这个范畴具有丰厚的履历,我信任他很快就会成为一个有代价而且活泼的奉献者。
- 将计划/会商/查询拜访的互动历程搬出Sun的办公室,搬到专家组中。
- 赐与专家组更多一手信息(大概最少一个快照)。
固然,看起来良多会商和完成的决意都是在Sun公司里凭空捏造,在决意制定出来后,只是把专家组看做是证实该决意的读者。现实上,以上这两点恰是招致PeterKriens不想到场的祸首罪魁:但是,JSR277如今包括两个好的(资本库和言语模块)和一个坏的(JAM)部分。就在JavaOne2008之前,Stanley公布了一个冗长的OSGi互操纵性文档。这个文档不但在细节上十分大略,并且还提到了还没有发布的初期草稿#2(EDR2)的良多中央。我问了专家构成员BJHargrave[Equinox-ed]和RichardHall[Felix-ed]是不是他们看到了这个草稿,但是他们也并未看到。比来我在JSR277邮件列表中埋怨缺少会商,看起来事情都在背后举行。在Alex和Stanley先容JSR277的过程当中,我分明地熟悉到幕后已做了良多事情了;而这统统并未在邮件列表长进行过任何交换。关于在坐的列位其实不晓得几近一切的工具都没有经由专家组的会商。假如独一的选择就是批准Sun在幕后所做的事情的话,那我到场专家组另有甚么意义呢?假如在JavaOne演示的还没有公布的EDR2成为JSR277终极的了局时,有几工具必要改动?当年夜部合作作已完成时,我还必要到场专家组吗?在这类情形下,你能完成几基础的改动?
我们如今处在一个关头时代。只管我很想列入关于Java言语模块和堆栈的会商,可是我不克不及对Java中的模块体系卖力,由于它毫无事理地弄出这么多庞大的工具出来。我至心但愿Sun能捉住这拯救稻草,保持JAM,接纳更加复杂的体例在全部体系中利用OSGi元数据。这是我在已往的几个月中得出的结论! 同时,Sun的不休立异也意味着OSGi的交互正在不休前进。AlexBuckley已到场了277专家组(卖力上述的JSR294的简化事情,这真是可喜可贺啊);同时MandyChung已被付与OSGi互操纵性方面的事情。
看起来Sun已在存眷了,还算实时。在往年的JavaOne上,我们报导了基于OSGi的SpringSource使用平台和运转在OSGi上的Glassfish。OSGi最好理论展现(PDF)激起了人们的乐趣,自从JavaOne后,在论坛和博客上关于包(bundles)的会商就在延续增加。我们但愿JSR277EDR2会切记这些倡议而且将OSGi和JSR277更严密地分离在一同。
检察英文原文:AreJSR277andOSGicomingtogether?
来自:http://www.infoq.com/cn/news/2008/05/jsr277-osgi
IDE是好。java中的IDE更是百花齐放,你用jbuilder能说jbuilder赶不上vs吗?用eclipse,net网页编程beans也很舒服啊。我就不明白“稍微差一些”那一些是从哪里差来的。 |