模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
新闻
Bruce Eckel谈Python、Java、Flex及RIA
作者 Jon Rose 译者 张龙 发布于 2009年5月9日 上午11时17分
在本文中InfoQ有幸采访到了Bruce Eckel以了解其对RIA前景的看法及目前所从事的工作，因为他最近与人合著了一本书，名为First Steps in Flex。
首先InfoQ问到Bruce最近在忙什么呢：
前不久在滑雪的时候我把腿摔坏了，因此过去的9周我一直在恢复。此前一直都没受过什么伤，这也算是一个新体验吧，我做了外科手术、全身麻醉以及各种恢复治疗——太多新体验了。尤其是全身麻醉，我用了好几周的时间才从中恢复过来，真的。我就呆在那，无所事事，脑子的反应速度也变慢了，在最后恢复过来时，我才真切的感觉到意识的存在。在无所事事的那段时间内，你真的会想去做些事情。
此前我就问过自己“我现在想要做些什么呢”，在腿摔坏后这种感觉尤为明显。继续从事着之前所做的事情已经无法满足我的心愿了——我想干点有意思的事情。
我开始编写关于Python书籍的一个主要原因就是我发现自己最喜欢做的还是咨询工作，这个工作经常需要和很多公司打交道，而这些公司当中有一些已经决定采用Python了（我想肯定也有不少公司开始使用动态语言，但我的经验主要还是在Python上）。这个工作极具挑战性，每天我都感觉像是在前苏联一样——他们不会对我进行搜身检查，但也差不了多少，在我去浴室的时候总有人陪着我（因为腿受伤了）。但这些公司的技术经理还是坚持使用Python而不管我的兴趣所在（然而，现在我知道了负责Python提交的公司的作用和有决断力的个人对其的推动力之间的差别了）。
一般来说，愿意使用Python进行开发的公司文化一定是很开放且享受这么做的。有些公司坚持使用某种语言的原因仅在于它能提供一些“直接（directing）”的特性（策略性不强的一些人称其为“束缚与铁律”特性），这种公司更多的是希望降低风险而不是进行挖掘或是不断试验。当然在很多情况下，降低风险是必要的，但我却觉得这么做不太爽。快速试验与边缘挖掘才是我的兴趣所在，在我的印象中，选择Python的公司更倾向于我的这种做法，我也很愿意与这样的公司合作。
也就是说我又回到了“过去为自己工作的那种状态”以便与那些公司进行合作。写写书，在各种会议上发表演讲。虽说这种工作方式不是我发明的，但到目前为止，我还没有找到其他更适合的方式。
当然了，我还一直在为Open Spaces events进行创作，同时这些创作也让人感到满意。在一场研讨会之后（整整一周我都在不停的说，同时大量的试验也让人精疲力竭，这么做的目的是为了让与会者都能步调一致的进行学习，你可能会觉得这有点傻），我简直是身心俱疲，短时间内绝不想再来一次了。但在Open Spaces event上的演讲结束后，我总是感到非常失望并且下周也不想再演讲了。我想知道如何才能实现双赢。这也是James Ward和我编写“First Steps in Flex”一书的原因之一，为了让我们的“Flex Jams”在市场上打开名号。
前几年我一直活跃在当地的剧院中。Crested Butte里充满了众多富有才华的人们，我们也组建了一个活跃的theater group，要想让自己的作品在其中站住脚可不是那么容易的事情——目前我已经在5、6个剧目中一显身手了。上一个叫做“Into the Woods”，此前我可没演过音乐剧，但最后还是出演了“长发女王”。加上“灰姑娘”一剧，我们上演了最甜美的二重奏，这么说可能不太恰当，因为很多其他演员的工作要比我们更辛苦。我的伙伴王子刚刚从戏剧学校毕业，他学的是声学专业——他的母亲是伦敦歌剧院的首席女主角——因此要想赶上他对我来说可是个挑战。但这整个经历中最值得称道的地方是能与这么多认真且专业（虽然只是大家在业余时间打造出的产品）的人们一同工作实在是可遇不可求。这也让我对团队有了更深刻的认识，能成为卓越团队的一分子是件多么高兴的事啊。
随即我开始阅读大量关于软件团队和工作方式的书籍。这倒不是因为我觉得自己要成为团队经理了，而是因为理解团队对于一个咨询师来说是个重要的技能，这也是这么多年来我一直在不懈追求的东西。
剧院所做的一件事就是加上了当地作者所编写的10分钟长的剧本，我也这么做了好几次。我已经开始编写大型的剧本同时还参加了当地的一个writing group。过去的几年中我参加了各种小说讲习班，发现小说要比其他文学作品难写的多（可能这就是为什么每年只有5,000部小说出版但却有50,000个散文书出版的原因所在吧）。
过去几年我参加了绘画讲习班， 所以现在也开始学习绘画了（我觉得参加好的讲习班是种习惯；从中能学到不少东西，但同时也希望这些经验能对自身改进起到帮助作用）。在我参加的上个讲习班中，老师总是强调“我们不是用刷子在画布上绘画 ，而仅仅是在平面上绘制一些标记而已”。我觉得这对我来说极大地降低了绘画的入门难度，不用担心画的正确与否。做就行了。我发现信手涂鸦要比循规蹈矩的画更好玩。不得不说的是我还没有掌握绘画的精髓，最大的问题在于我做事情有些太谨小慎微了，生怕将好的东西搞糟了。
最近的一件事就是我设计了Pycon 2009大会的T-shirt，上面的画是我画的（一个抽象的易经22卦，代表了“优雅与美丽“）。遗憾的是，因为我的腿伤无法参加今年的大会了，但有人告诉我，我画的画有些超现实主义。
我觉得这些经历对软件世界是非常有帮助的。多做试验，多多探索，而不是呆坐在那傻想着，这么做会对项目的进展起到非常大的帮助作用。
接下来，Bruce与我们一起分享了其最近发布的Flex新书：
”First Steps in Flex“是我与James Ward合著的，他可是个Adobe Flex布道者。我们想写点东西以便让程序员能够轻松上手Flex，因此这本书很小巧，也没几章。这么做可以帮助大家集中精力于关键的事务上；翻开它你会有这种感觉”这章可真短，搞定它没问题“。下一章也如此...整本书非常简练，为了达到这个目的我们需要将那些读者完全不需要了解的内容去掉并坚持其本质特性。通过这种方式，人们可以漫步在书中，同时感觉自己可以完成一些事情了，但他们却不会深陷于大量的信息中。这花费了我们大量的时间和精力将Flex的精华抽取出来，但对于结果我是非常满意的。
之后，InfoQ向Bruce问到他对当前的RIA前景有何高见：
我觉得最重要的事情就是RIA是个真实的东西，而不仅仅是Adobe制造出来的术语。人们已经接受了这样一个事实：HTML/CSS和一点点的Javascript并不会对这么多的Web应用起到颠覆性的作用（当然了，尽管在很多情况下这是正确的处理方式）。用户对丰富及更具响应性Web应用的期望越来越高，而站点却无法提供这些体验，同时也无法对付Web那些古怪的问题，这时你就需要在一个高质量的平台上编程了。
我越来越感觉到我们所陷入的浏览器“标准”始终无法统一起来，也无法让我们信赖，甚至连可用性都没法保证。看看CSS吧，从概念上讲它很棒，但却无法让我们在浏览器上进行一致的编程。HTML本身更是乱的一团糟。并没有什么标准的方式来包含头（headers）和脚（footers）（是的，SSI可以做到这一点，但它总是依赖于特定的服务器配置，而我们却不能这么做），这样人们转向了PHP，接下来采取了我们称之为“比Perl要好的东西”，而这仅仅是由于它不会令让我们过早的陷入到麻烦当中（我使用过PHP，但仅仅是使用过而已）。
底线就是：我们需要在浏览器和RIA之间加上一个中间层；浏览器技术始终无法独挡一面。甚至连GWT这样的技术也仅仅是降低了平台依赖性问题而并不会消除该问题。与Ajax一样——我们仍需手工调整代码以便其能够工作在多个浏览器上。工作量虽然少了，但这毕竟不是我想做的事情。既然加上一个中间层就能完全消除这个问题，那为何还浪费公司的资源在这些问题上呢？
我是个Flex迷，因为所有平台都支持Flash player。Silverlight宣称支持Linux，但我不知道其支持力度如何。毕竟过去微软对于非Windows平台的支持并不尽如人意。Mac平台上最新版的Office尚不能使用Windows系统上的宏，而宏对于我来说是非常重要的，这也导致了很多问题，不仅仅是我，其他人也一样。尽管微软有着这样那样的借口，但谁管你呢？你只能任人摆布。如果微软宣布不再支持Mac版的Silverlight，那他们肯定也会有借口。如果Linux对其的威胁变大时，他们也一定有理由说你无法在Linux上使用Silverlight了，谁管你？如果你过于依赖他的话，我只能说霉运离你不远了。我注意到Netflix使用了Silverlight进行视频点播，不过到现在为止我还无法在Mac上的Firefox中使用该功能——可能过不久该功能就会出现，但如果不出现呢？Netflix会丧失大量用户，同时他们可能已经丧失一些Linux用户了。Adobe也是一家大公司，他们也可以变来变去，但他们却支持所有的平台，而微软却有一个操作系统要推销。Silverlight的设计很棒，他们从Flex上也汲取了不少精华。我觉得有竞争是好事，这样会刺激Adobe更加努力。但如果你问我更喜欢Flex还是Silverlight的话，我会说“放着好好的东西不用，为什么要冒险使用微软的东西呢？”
接下来，InfoQ问到对于用户界面来说，工业界不断转向客户端运行时是不是件好事呢：
绝对是件好事；我现在就在干这事呢。但我忘记说JavaFX了。在JavaPosse Roundup 09上，我们用dojo编写了少量代码，而Dick Wall用Flex（借助于James Ward的帮助）和JavaFX（借助于Tor Norbye的帮助，他就在JavaFX团队）实现了其“Flubber”应用。其实这些东西就是在我家完成的，不过由于刚刚做完手术，正在恢复中，我没法给出太多的细节。但给我留下深刻印象的是使用这两种语言可以实现同样的效果。我觉得用Flex实现更简单一些，但JavaFX的实现结果还是给我留下了深刻的印象。还有，JavaFX看起来很像是ActionScript，但却对语言增加了一些更灵活的改进，我觉得这会对ActionScript产生小小的冲击，好事一桩。
之后，InfoQ问到Flex要想取得成功，是否需要借助于Java的帮助：
我认为Flex-to-Java桥非常重要，但Sun却不对其提供支持，太差劲了。在这件事上，Adobe也好不到哪去。有一些开源的工具可以实现这一点，同时我认为还需要更多的商业公司来支持这些开源项目。即便他们不招人或是不完全支持，但看在钱的份上这么做也是有好处的。我觉得只要有人能从这些项目中赚到钱就会有很多公司开始支持他们了。能够简化该过程的任何事情都会让所有人受益无穷。
InfoQ又问到，除了Java以外还有哪些语言能与Flex搭配使用：
我所完成的大多数项目都是使用Python作为Flex后端的。有几种方法可以实现这一点，但Twisted程序库对Flex通信提供了直接的支持，同时还是异步的，很完美。
Ruby也支持与Flex的通信。我觉得动态语言是非常棒的后端，通过他们你可以做到最好——实现真正的快速开发，包括漂亮的UI与后端的业务逻辑。
最后，InfoQ问到Bruce最近是否还在从事着Java方面的工作：
偶尔做点设计上的咨询，仅此而已。
我感觉“Thinking in Java”到第四版也就差不多了——到现在为止我基本上已经重写了四次，到上次写完后我觉得应该差不多了。所以我不打算再写新版本，不过我还会以附录的方式对第四版提供支持，增加一些自从第四版之后新出的重要细节和语言特性。但我希望社区能为这本书作出贡献，因此我发布了该书的电子版。这么做能否号召起社区就是另一回事了——这也是我对待Python这本书的方式，或许到那时我能想出更好的办法来处理这些事。
可以通过Bruce的博客来了解其更多的见地。
查看英文原文：Bruce Eckel on Python, Java, Flex, and RIAs
技术爱好者过着自由的生活
发表人
国栋 陈
发表于
2009年5月9日 下午10时53分
喜欢Python
发表人
Allen Long
发表于
2009年5月10日 上午6时38分
羡慕中。。。
发表人
shuhai Tang
发表于
2009年5月11日 上午3时13分
崇拜
发表人
guo ufi
发表于
2009年5月12日 上午4时44分
希望和Bruce一样
发表人
Eric Cartman
发表于
2009年5月14日 下午9时25分
Re: 希望和Bruce一样
发表人
Xiaogang Guo
发表于
2009年5月16日 下午2时41分
-
Bruce Eckel是快乐地过着自己的生活的人，令人羡慕。
-
Python: 最自由、最开放、最享受的动态语言 :)
Huihoo - Freedom Driven huihoo.com -
不知道自己什么时候能像Bruce那样生活！！！
-
努力拼搏！
-
做自己喜欢做的事
-
Eric Cartman的名言：Screw you guys, I'm going home!
6 条回复
关注此讨论 回复