Read Sean

本文部分内容和灵感来自eclipse.org网站，特此声明。更多内容，请参考：

http://eclipse.org/articles/Article-SWT-Design-2/SWT-Design-2.html

 

由于SWT直接跟操作系统打交道，所以我们需要在处理系统的图形资源时格外小心，以免不必要的资源泄漏。所幸SWT提供了很好的资源管理机制，我们绝大多数情况下需要做的只是确保两条原则：

第一条原则 – 谁分配谁销毁

第二条原则 – 父控件销毁的同时销毁子控件

 

下面我们分别来看一看这两条在实际中是如何体现的。

先看第一条原则。乍一看这似乎是废话，但是在实际中往往并非那么简单。首先，构造方法不等于分配资源，实际上分配资源可以发生在一个类中的任何地方以及一个对象生命周期的任何时候，只要你的代码告诉操作系统这样做。你必须保证所有由你分配的资源当你不再使用时调用其dispose()方法；同时你也必须保证所有不是由你分配的资源不要随便调用其dispose()方法，否则很可能会影响到实际分配的那段相关代码的正常工作。好消息是，为了明确和简化这第一条原则所规定的分工，SWT在设计之初就确定下来，所有基于系统资源的SWT类都在其构造方法中完成所有所需的资源分配，在其他方法中则没有任何分配系统资源的动作，所以我们可以幸运的这样看待SWT的资源管理：如果你调用了某个SWT类的构造方法，那么就由你来调用其dispose()方法释放资源；如果你没有调用某个SWT类的构造方法，即便你使用了这个类的实例，也不应该由你来调用其dispose()方法。就是这么明确。

比方讲，你new了一个Font对象，那么当你不再需要它时，就应该调用dispose()；如果你通过某个控件的getFont()方法取得一个Font对象并使用后，你不应该去销毁它，而应该交给那个具体的控件去处理。

对于第二条原则，SWT有一个很好的机制去支持它，那就是，所有的SWT控件，具体讲，Composite类及其子类的实例，都必须有一个父控件，这个父控件的引用在子控件的构造方法中被传入。需要注意的是，所有这些控件的不带参数的构造方法都只有默认访问级别，于是我们不能在自己的SWT程序中直接调用这样的默认构造方法而只能提供一个父控件的引用，而在Widget类（Composit的父类）的带参数构造方法中，它会调用如下方法：

进而：

这样的检查保证了任何控件在创建时都有父控件。当我们调用某个Composite的dispose()方法时，它会调用：

其中的_getChildren()方法通过OS对象的方法遍历控件的子控件，然后汇总到一起分别调用releaseResources()方法释放控件和句柄。

回到上次的SimplestSWT的例子：

 

这当中，Display是一个顶层的设备，它继承自Device类，而Device类实现了Drawable接口。Shell的父类是Decoration，而Decoration继承自Canvas，Canvas继承自Composite，最终这条继承链一直连到Widget类。我们在创建Shell示例的时候，需要告诉构造方法它的父控件是什么，在这里就是display。于是当我们最后调用display.dispose()时，虽然我们没有明确写shell.dispose()，我们的Shell实例也随之销毁了。

这就是SWT的资源管理机制，稍有例外的是MenuItem的setMenu()方法和Control的setMenu()方法，它们通过显式调用setMenu的方式注册自己的父控件。

 

 

本文部分内容和灵感来自eclipse.org网站，特此声明。更多内容，请参考：

http://eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

 

众所周知，SWT与Swing最大的不同就是它直接使用操作系统提供的现成的本地图形接口，于是具备本地化的Look & Feel。但是它是怎么做到这一点的呢，当然是通过JNI。我们来看一个例子，假定我们使用Win32的API。

我们现在有一个文本框text，通过如下的代码，我们给它一个字符串，并让它选择/highlight从3~5（[3,5]）的字符。

在Windows下，这个setSelection方法是怎么实现的呢？我们可以看看源码：

做过Windows编程的朋友可能一下子就认出了这个SendMessage，这不就是Win32 API中用于向窗体发送消息的函数吗？呵呵，没错，我们再来看一下这个SendMessage方法的原型：

我们看到了两个版本，一个版本针对Unicode，另一个版本针对ASCII，正好Win32 API也是如此，我们在这里看到的是native的方法，这意味着具体还有一组JNI的C代码来直接与操作系统的函数打交道：

看到这里，你也许已经恍然大悟：SWT所做的无非就是把Win32的API简单的包装了一下，我们在SWT这一层调用的方法、传递的参数被原封不动的代理到了Win32层。这就是SWT的核心思想。SWT有一个很重要的设计原则，那就是，SWT的API一对一的封装OS的API，完全忠实于操作系统的API实现的行为，如果有bug，那也是OS的bug，它不会尝试去“纠正”操作系统，因为那样会潜在的破坏本地化的一些行为。忠实于OS也使得调用者不必但心自己的SWT程序会跟OS的本地GUI有不一致的地方，如有必要直接参考MSDN即可。SWT其实就是这样一个thin wrapper，我们通过它可以方便的访问Win32的图形API，为我们的应用程序提供native的Look & Feel。

下面给出一个完整的SWT示例：

 

本文假定读者使用Windows操作系统+JDK 1.4，其他平台和JDK版本应该也是八九不离十。

为了编译和运行SWT程序，我们有两种选择：1- 使用Eclipse SDK；2- 下载单独的SWT二进制文件和源文件。

随Eclipse SDK，我们可以在它的plugins目录下找到SWT的二进制文件，通常的目录名称是：org.eclipse.swt.win32_xxxx，后缀是版本号，在这个目录下有os和ws两个子目录，内容分别是SWT的JNI库和swt.jar。

如果不是使用Eclipse来开发，或者需要SWT的源文件，那么需要下载单独的SWT二进制和源文件包，在下面的地址可以找到：

http://mirror.pacific.net.au/eclipse/eclipse/downloads/drops/R-3.0.1-200409161125/swt-3.0.1-win32.zip

这个zip文件解包以后包含JNI库（一些DLL）和swt.jar，以及swtsrc.zip，这个swtsrc就是我们SWT的源文件了，包括C和Java的源代码。

为了运行SWT程序，我们需要首先编译我们SWT的代码，这个时候需要告诉编译器swt.jar的位置；编译成功以后，我们除了指明classpath包含swt.jar之外，需要在命令行告诉java.exe另一个参数，那就是java.library.path，看上去大概是这个样子：

java -cp %SWT_HOME%\swt.jar SimplestSWT -Djava.library.path=%SWT_HOME%

如果你使用的是Eclipse SDK 3.1M5a或者更新的版本，你可以直接右键.java文件选择Run As -> SWT Application，则不用在命令行写那么长的参数了。

比较有意思的是，我们可以在eclipse.org的SWT下载页面看到目前SWT支持的平台：

•        Windows 98/ME/2000/XP
•        Windows CE (ARM PocketPC)
•        Windows CE (ARM PocketPC, J2ME profile)
•        Linux (x86/Motif)
•        Linux (x86/GTK 2)
•        Linux (AMD 64/GTK 2)
•        Solaris 8 (SPARC/Motif)
•        QNX (x86/Photon)
•        AIX (PPC/Motif)
•        HP-UX (HP9000/Motif)      
•        Mac OSX (Mac/Carbon)

呵呵，支持的平台虽然有限，不过还是蛮多了。

 

第15届Jolt大奖评选结果已经公布，可以在以下地址下载PDF：

http://www.sdmagazine.com/pressroom/jolt_winners_2005.pdf

比较有意思的是：Eclipse 3.0力压IntelliJ IDEA 4.5成为语言和开发环境类的Jolt奖得主，可能出于Eclipse开源的关系；Hibernate 2.1力压J2SE (TM) 5.0获得了类库、框架和组件类的Jolt大奖。

这些结果也许会出乎一些朋友的意料甚至反感，我想说的是，这仅仅是一个相对权威的杂志的一次常规的评选结果，当然也能够在一定程度上反映出获奖者的实际水平和用户/市场接受度，但是能够入围的产品都是相当不错的。

期待在未来能有国人的作品上榜。

今天听新闻说肯德基一直以来出售的新奥尔良烤翅和新奥尔良烤鸡腿堡的调料被查出含有致癌物质苏丹红一号。看来对这些产品也需要多加留意了。虽然肯德基已经 在所有门店停止了这两种产品的销售，并承诺一周内恢复供应不含苏丹红的以上两款产品，但是像起来还是令人后怕，肯德基也会出这档子事儿？还让不让人安心去 吃了？

从目前公布的名单和相关报道看，除了肯德基，像麦当劳、亨氏这样的大品牌恐怕在短期内都难洗清苏丹红事件对它们造成的负面影响。

背景资料：
苏丹红一号是一种红色染料，用于为溶剂、油、蜡、汽油增色以及鞋、地板等的增光。 研究表明，苏丹红一号具有致癌性，中国和欧盟都禁止其用于食品生产。苏丹红事件牵涉到食品安全问题。2005年2月18日，英国食品标准署就食用含有添加 苏丹红色素的食品向消费者发出警告，并在其网站上公布了亨氏、联合利华、麦当劳等30家企业生产的可能含有苏丹红一号的产品清单。截至2月21日，清单上 的产品增加到了419种，这些产品包括虾色拉、泡面、熟肉、馅饼、辣椒粉、调味酱等。英国食品标准署已下令召回上述食品。事件爆发后，引起了世界媒体的一 片哗然。

     摘要: 鉴于Java社群不时的也应该了解一下对手的信息作为参考，我将自己在博客园的一篇随笔摘录如下： 原文见：http://www.cnblogs.com/sean/archive/2005/03/15/119341.html  阅读全文

由kukoo的blog上面提供的链接来看，最近似乎NetBeans和Eclipse阵营又开始了新一轮的口水战？我们先看看这两个对手之间近来都发生了些什么事：

首先是J2SE 5.0的发布，几乎同时NetBeans就宣布了全面的新语法支持，并且发布了新的4.0版，以及同JDK的捆绑版；而Eclipse则花了相当一段时间来完善对J2SE 5.0新语法的兼容，并且至今还没有哪个release版本的Eclipse JDT宣称100%支持J2SE 5.0。这当然并没有出乎我们的意料：NetBeans后面是谁？SUN是也，这就难怪会有这样的区别。

然后是刚刚结束的Eclipse CON 2005，在这次大会上，虽然主角还是离不开Eclipse背后的IBM，我们还是看到了其他许多大厂商的身影，比较重量级的有BEA，Borland等等，它们都纷纷宣布加入Eclipse的"战略开发"阵营；相较Eclipse，NetBeans受到的关注日渐减少，当然，还是有不少NetBeans 的支持者在不停的振臂疾呼，然而，NetBeans和SUN似乎正不可避免的逐步走向孤立？

从体系结构上讲，Eclipse和NetBeans基本上走的是一致的路线：Platform + Java IDE + Plugins，也许最大的不同是Eclipse在某种程度上鼓励使用SWT，而NetBeans则是更"纯"的AWT/Swing。

不知道大家有没有类似的感觉：当今IT界有一个很重要的现象，那就是"得程序员之心者得天下"，这个是针对IDE和IDE背后的平台而言的。像 Microsoft、SUN、IBM、Borland这样的大公司当然也非常明白这一点，于是纷纷都把大笔资金砸到IDE的开发中，之前我的一篇blog 也提到Eclipse出现的背后有一个动机是赶超Visual Studio系列。

在Eclipse和NetBeans竞争的背后，IBM想得更多是如何将大量的开发人员，不论是Java、C/C++、还是别的什么语言吸引到同一个平台下，进而创造更多潜在的IBM客户（而不是微软）；而SUN似乎更希望IBM按照规则出牌，对类似SWT的东西能够放到JCP这样由SUN控制的，相对标准化的流程中，而不是自成体系。很多人也许希望SWT能够被JCP，然而现在看来这真的最多只是一个希望而已了，IBM似乎也没有理由，或者至少不情愿这样做。我们可以追述到一年多以前，当SUN决定不参与Eclipse计划那个时候，从当时两方的态度和声明也许就已经多少成就了现今这样尴尬的局面。

从纯技术上讲，Eclipse和NetBeans也许真的是萝卜青菜各有所爱，但想想背后的这些故事，也许能够更好的理解近来某些相关言论的出发点。

说了以上这么多相对中立的话，下面也说一些也许更加代表我个人的观点：

Eclipse我已经用了很长一段时间了，在这之前，我偶尔也用一些其他的Java IDE如JBuilder等，自从用上了Eclipse，至今我再没有离开过它，哪怕WSAD那也是基于Eclipse的，坦白说，我真的喜欢上了 Eclipse。它的开放性远非NetBeans能及，作为完全开放的平台，它可以很方便的扩展，而且有大量的开源项目支持，Eclipse正变得越来越成熟，我也无法抵制自己做插件的欲望和冲动。可以说，Eclipse是目前唯一可以与微软Visual Studio叫板的IDE。它不排斥任何东西，有一天哪怕你用它来做C#又有什么不可以呢？Eclipse给人最明显的感觉就是实用，而不是为了某种技术而技术，同时它也提供给开发人员更多更开放的选择。

NetBeans也不是一点没接触过，3.6的时候就下下来看过，没什么吸引我的，罢了。最近跟着JDK一起下过4.0，甚至也单独下过4.1，也没有留下什么好的印象：

我的系统是Windows XP，安装4.1到8%时，停住了，说明文字是"Building Storage..."，重试N遍都是这样，放弃。安装4.0的时候，看到NetBeans的最小内存要求384MB，推荐512MB，我只有 256MB，狠狠心还是装了，果然速度受到了内存的影响，感觉非常明显，其界面显示和易用性也有些让人不敢恭维。然而我的Eclipse SDK 3.1M5a确感觉不到太慢，界面整洁、清晰、漂亮。

不知道这些能不能说服你，说服我自己继续使用Eclipse是足够了。

在之前的blog中间我们曾经提到过3.1M5a这个版本的性能似乎并不尽如人意，许多使用报告和用户反馈似乎在支持这个结论。如果你像我一样，想弄个究竟的话，下面有几个链接可以给我们一些有价值的参考，它们是eclipse.org官方公布的3.1M5a相对于3.0版本的对比测试结果：（由于 3.1M5a发布版本的构建时间是2月19号15时整，所以报告中采用的版本号I20050219-1500跟3.1M5a其实是一致的）

[Overall|整体表现]
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/performance/performance.php
[org.eclipse.ui|Eclipse界面]
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/performance/org.eclipse.ui.php
[org.eclipse.jdt.core|JDT核心模块]
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/performance/org.eclipse.jdt.core.php
[org.eclipse.jdt.ui|JDT界面]
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/performance/org.eclipse.jdt.ui.php
[org.eclipse.jdt.text|JDT文本编辑器]
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/performance/org.eclipse.jdt.text.php

具体答案是什么还是大家自己看吧，希望到了3.1版正式release的时候我们能看到比3.0性能更加优异的Eclipse。

我们来看一段最简单的SWT程序是什么样子：



这段代码运行时会显示一个空的窗体。比较有意思的是Shell shell = new Shell(display);这一句，通过它我们可以了解到：在SWT中，子控件在构建时会传入包含该子控件的母控件引用，更进一步，在一个母控件被销毁时，包含的自控件也会自动被销毁。几乎所有常见的SWT控件都是以这种方式处理的。由于SWT使用OS自带的API，SWT控件的创建和销毁就跟纯Java实现有些不一样。

在接触SWT之前，总觉得它遥不可及，真正看到具体的代码后才发觉，原来它近在咫尺。

上一篇blog我提到了新发布的Eclipse SDK 3.1M5a，在接下来的系列文章中，我会零散的记录我对Eclipse一些相关内容，如SWT、PDE、RCP这些的学习过程和心得，并非作为正式的教程或者严谨的文档，只是想到哪儿说到哪儿了。

更早的一篇blog，我提到Eclipse SDK 3.1M4的发布，其实在那个时候，Eclipse的JDT已经支持所有J2SE 5.0的新语法了，只是有一些bug和重构的功能还没有完全做好，3.1M5a在这个基础上改掉了一些bug，新增了一些针对J2SE 5.0的代码操作，就像Kukoo说的，3.1M5a在某些方面还不如3.0，但我相信正式的3.1推出以后会比3.0有很大的提高，单对J2SE 5.0的全面支持就很有吸引力。

如果你对这个3.1M5a的版本的JDT UI对J2SE 5.0源文件支持度感兴趣，可以看看这里：

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/jdt-ui-home/r3_1/j2se50/Status.html?rev=1.48

在进一步学习Eclipse之前，我们需要搞清楚一些基本概念。

 

# What is eclipse?

Eclipse是由IBM最初发起并最终开源的一个功能强大的开发平台，它包含3个项目：the Eclipse Project、the Eclipse Tools Project和the Eclipse Technology Project。

 

# What is the Eclipse Project?

Eclipse项目是一个健壮、功能丰富、商用品质的业界软件开发平台，集成了相当多的工具，它包含3个子项目：Platform、JDT和PDE。

 

# What is the Eclipse Platform?

Eclipse平台用于整合不同厂商、机构或个人的工具，把它们无缝的集成到一起，使得整个Eclipse的框架非常易于扩展。

 

# What is JDT?

JDT的全称是Java Development Tools，在Eclipse平台上提供的一款功能强大的Java IDE。

 

# What is PDE?

PDE的全称是Plug-in Development Environment，用于对插件开发的支持。

 

# What is the Eclipse Tools Project?

Eclipse工具项目包含相当多的开源和非开源的工具，用于支持Eclipse平台，这个项目的存在可以协调各方开发人员共同开发某些功能的插件，避免不必要的重复劳动，以及确保工具之间可以良好的集成。

 

# What is the Eclipse Technology Project?

Eclipse技术项目的任务是为那些开源的开发人员、学者等提供一个参与到Eclipse发展进程中的渠道。分为科研、创新和教育三个分支：科研分支研究Eclipse相关领域的问题如开发语言、工具和开发环境等；创新分支包括了一些小型的、非正式的项目为Eclipse开发新的功能；教育分支重点是提供教学材料和课程等。

 

# What is the Eclipse SDK?

Eclipse SDK是Eclipse项目的三个子项目，平台、JDT和PDE的产品合集，提供单独下载。这些产品整合在一起，为开发人员提供功能丰富而便捷的开发环境。

 

# What is SWT?

SWT的全称是Standard Widget Toolkit，标准控件工具包，提供构建用户图形界面的API，由于是直接使用操作系统现有的图形接口（如果有的话），速度和性能在很大程度上不受JVM的限制。对于Java开发者来说是好事，在AWT和Swing之外，我们又多了一套极具吸引力的图形API。支持多种平台，我们可以看到Eclipse的界面就是SWT画的，足见它的实力。 

 

更多内容，参考：

http://eclipse.org/eclipse/faq/eclipse-faq.html

Google's latest move is the beta release of its Desktop search engine, which, to some extent, is considered an "invasion" into our beloved (or behated?) Windows platform.

I tried it for some time now, and it seems very interesting and powerful.
http://desktop.google.com/

最近忙得昏头转向的，还没有仔细看Eclipse CON 2005的内容，却偶然发现Eclipse SDK的新的Milestone build已经可以下载，版本号3.1M5a。印象中这次的release已经等了很长时间了。

接下来打算抽时间看一下它的新特性，J2SE 5.0兼容度，以及SWT、PDE、RCP等内容（谢谢Kukoo的大力推荐）。会同步推出相关blog文章。

新版本下载地址：

http://mirror.pacific.net.au/eclipse/eclipse/downloads/drops/S-3.1M5a-200502191500/eclipse-SDK-3.1M5a-win32.zip

我试过，速度还可以。

 

今年的Eclipse CON年度大会于2月28日至3月3日在美国加州Burlingame的Hyatt Regent酒店隆重举行。3月3日上午，来自IBM Rational的Lee Nackman做了题为《Eclipse现象》的演讲。以下是eclipsepowered.org上的一篇相关报道的摘要。

 

原文见：

http://www.eclipsepowered.org/archives/2005/03/03/day-4-the-eclipse-phenomenon/

 

Nackman对Eclipse起源的介绍从1995-1998的那个年代开始，当时的IDE市场是微软Visual Studio的天下，Java的IDE以及类似WebLogic的服务器产品也才刚刚起步，而IBM当时的产品线相对混乱，虽然都挂了Visual Age的牌子，但实际上并不是集成到一起的产品

 

1998年左右，他们意识到应用程序服务器（中间件）市场竞争的关键是如何吸引开发人员为这些服务器写应用程序。于是他们想搭建一个可以让合作伙伴来完成空缺功能的框架，而事实上IBM当时的各个实验室往往在用不同的技术做着相同的事。

 

几个人合作提交了一份展望未来的提案给IBM的各个团队，在1998年11月他们通过会议达成共识：构建一个新的工具平台和一个新的Java IDE。当时一个叫OTI的分支机构正在开发一款支持plugin的IDE，于是最终的决定是由这个分支机构开发工具平台，由另一支IBM的团队负责构建第一个基于该平台的IBM产品。这就是为什么我们现在看到的Eclipse有两个不同版本的重量级项目：eclipse platform和eclipse JDT。

 

核心的决定包括：

u       将任务交给小型的、紧密的团队 – 概念上和理解上的一致相当重要；

u       构建一个可扩展的平台和一款优秀的Java IDE – 用来增加该平台的人气；

u       平台和IDE的团队紧密合作 – 于是有了干净的平台接口并且很好的反馈机制促成了更好的、正确的产品；

u       产品和平台团队分离 – 保证品台产品的完整和维护多个版本；

u       尽全力同Visual Studio在Windows环境竞争 – 这就是SWT背后的动机。

 

到2000年，一切进展都很顺利，于是他们打算开始把这个项目作为产品来开发，取代Visual Age。

 

关于Eclipse的名称，Nackman是这样解释的：当时所有以“e”开头的词都很时髦，虽然已经有不少公司/机构/产品都已经使用了这个名称，但是最终IBM还是决定采用“Eclipse”命名，一方面，eclipse这个单词声调很好；另一方面，他们想eclipse（日食/超越/遮盖）Visual Studio。笔者相信背后隐隐约约还有一个更合理的解释：遮挡住SUN的光芒。

 

接下来问题是如何推广Eclipse，让它广泛被接受？时间到了2001年，当时Visual Studio和微软的产品线继续壮大，厂商仍然不停地将开发人员引入到中间件的开发，类似Borland的公司也在推出不同的Java相关产品。这些Java阵营的公司/机构都在做自己的一套功能其实类似的东西，而不是在一起推一个成熟的产品线来同微软竞争。关键在于如何说服大家相信Eclipse就是这样一个平台。这就是为什么Eclipse最终走向了开源。

 

这个时期的IBM已经有了很多开源的经验，例如他们看到Apache的HTTP服务器发展的势头，于是在WebSphere中采用了Apache的技术，另一方面他们也积极的帮助类似Apache和Linux这样的技术社群，于是开源Eclipse就成了当时最合理的选择。

 

最终，Eclipse项目从IBM脱离，IBM同HP/SAP/Intel等公司合作，成立了Eclipse Foundation，从名字看就像是著名的Apache Foundation这样的非盈利性机构。

 

 

笔者的话

 

Eclipse目前最新的release版本号是3.0，在Eclipse SDK 3.1 M4中，J2SE 5.0的功能也得以实现。作为开发人员，我很高兴我今天能够使用到这样一款优秀的产品，并且Eclipse还在继续以惊人的速度稳步前进，足以看到其旺盛的生命力。如果你用过Eclipse，那么你一定会被它朴实的风格和强大的功能所吸引，如果你还没有开始你的Eclipse之旅，那么你还在犹豫什么呢？赶紧下一个试试吧！

 

http://eclipse.org/downloads/index.php

 

 

这话要从最近我改乘可刷卡公交车一事说起。

由于是外资高新企业，所以我现在的公司设在高新区，通常高新区离市区都比较远，我们这个高新区也不例外，每天上班至少需要40分钟。我们这里的公交车大致可以分为两种：可以刷卡的和不可以刷卡的。刷卡实行包月限次的优惠方式，即按照正常的情况估算，次数使用越多越划算。现实的情况有些让人为难，因为事实上从市区通往高新区的公交车有五路之多，其中两个可以刷卡，三个只收现金，而从我家到公司，至少有四套比较合理且经济的方案：

Plan A: 在一个有很多路车都停靠的站点(I)乘坐不可刷卡的公交车直达公司所在地；
Plan B: 在同一个站点(I)乘坐可以刷卡的公交车然后转可以刷卡的另一部公交车前往公司；
Plan C: 在另一个只有一部车的站点(II)乘坐可以刷卡的公交车然后转不可以刷卡的公交车前往公司；
Plan D: 在另一个只有一部车的站点(II)乘坐可以刷卡的公交车转另一部可以刷卡的公交车前往公司。

有很长一段时间，这根本不是一个问题，因为我认定了其中一个：Plan A，所以无论刮风下雨，我都会死等那部从我家直达公司的车。但是最近我越来越无法忍受该路公交车的服务水准：经常有一班无一班，动不动等上30分钟或者人多的挤也挤不上去，这对于上班需要准时和长时间坐车容易疲劳的上班族来讲，很难说可以接受。于是我就开始考虑另一种选择：使用公交卡，因此就有了上面的多种方案。

不要小看一张公交卡，乘车人的习惯一下子被这个分水岭一分为二：持卡的乘车人几乎都倾向于选择可以刷卡的公交车，而非持卡人则往往更习惯于绑定到有售票员的线路，因为这样不必担心没有零钱去投币。

最终我选择并很乐意的接受了Plan D，也很享受这份简单和轻松，一方面，我不必担心这套方案里的两部车会不准时到离谱的程度，另一方面，我也不用考虑其他任何外界因素，认准了这两路车即可。一卡在手，我心无忧，呵呵。这就是Plan B和Plan D的巨大区别。再看Plan C，它既不省事，也不省钱，所以没有吸引力。

从公司回家也有两个不同的站点可以选择：站点(III)只有一部公交车，而站点(IV)几乎所有公交车都会停。你估计也猜到了，我最终的选择是站点(III)。

这说明什么问题呢？说明我们内心其实会对“给你很多选择，或者没得选择，你更希望是哪一种”这样的问题有一个答案，多多少少反映出我们的心理图案。也许更多的人第一反应是：有选择当然是好事。我在很多时候脱口而出的答案也是前者，然而我最终的在公交车线路问题上的选择是：选择没有选择的选择，在很多模棱两可的选择或者诱惑面前，我会选择给我最少不安和烦躁的那一种。

这不得不让我联想到当今企业软件开发和外包的两大阵营：Java和.NET，在不同的层面上它们其实又处于完全不同的位置。

如果你在平台/中间件/开源类库和框架这个层面来看，Java给你很多选择，而.NET至少到目前为止大家看到的在这个层面还是相当局限，可以说.NET没有给你多少选择，换句话说，不用你去担心找不到合适的平台/中间件/类库，最终MS会给你一个solution。

如果你站在语言的层面看，Java的世界只认一种语言：Java，虽然也有其他的语言可以编译后在JVM中运行，但是很少有人用，所以一旦选定了Java，你基本上不用考虑其他语言；而.NET的世界里，只要有编译器可以把某种语言编译成MSIL，就可以使用这门语言来描述你的想法。

看，这两个家伙完全调了个儿。

最终的问题还是：给你很多选择，或者没的选择，你更希望是哪一种？前者意味着freedom、power of control、compitition、nervousness、和excitement；后者意味着easy decision、certainty、assurance、relaxation、或者peace。

其实生活中我们何尝不是在选择或者没得选择的快乐和痛苦的交错中度过每一天？对于我提出的这个问题，真的可以从答案和行动中看出一个人的性格，不信你试试？你会选择什么样的工作？喜欢怎样的生活方式？想不想结婚？持怎样的恋爱观？这些都是“给你很多选择，或者没的选择，你更希望是哪一种”这个问题在现实中的例子。对了，你有没有看过《海上钢琴师》，英语片名"The Legend of 1900"，里面的那个钢琴高手最终选择留在船上，换作是你，你会怎么选？

这是一部相当有味道的电影，中文片名叫做《再见列宁》，2003年上映。



从名字上看你也许能一下子就看出来这大概是一部政治电影，没错，它反映的是1990年德国柏林墙被拆除的那个年代当时东德一个普通家庭的故事，这当中当然不可避免的会有政治的成分。但是我不想说这些，这部片子吸引我的是它的另一个视角：一个男孩到男人的成长过程、遇到的挫折、以及他对母亲的爱。

故事中年轻的主人公参加一次示威游行，被警察抓走，当时他的母亲看到这一幕便昏厥过去，经检查，她患有心脏病，并且这一睡就昏迷不醒。男孩的父亲早在主人公儿时就偷渡到了西德，母亲是含辛茹苦将他和他姐姐带大。这个时候主人公意识到他的鲁莽和冲动会给他的家庭带来多大的不幸，于是他决心陪伴母亲直到她苏醒过来。

在母亲昏迷过程中，德国发生了翻天覆地的变化，东德和西德统一了，他们家的日子也不断在发生着新的琐事。主人公也逐渐长大，有了自己的初恋。

终于有一天，他的母亲醒了。

这个时候问题来了：根据医生的劝告，她的母亲不能承受任何重大的刺激，国家统一的大事当然也就成了绝对不能让她知道的秘密。于是男孩决定用他力所能及的方式让母亲感觉不到这一巨大变化。可以想象一下这有多么不容易：报纸、电视、收音机、邻居、家人、窗外的一草一木，每一样都极有可能使他的计划泡汤。于是他开始尽他的最大努力向他的母亲隐瞒真相。屋里的家具全部换成原来的，罐头也"旧瓶装新酒"，收音机和电视机播放录制好的节目，甚至不惜代价自己录制新闻，有时候甚至是为了不小心让母亲看到的广告牌自己编造一些新闻来自圆其说......等等等等。

最终......他的母亲在幸福中离开了人世。说她幸福，并非是肤浅的说她认为东德比西德好，或者是任何政治上的原因；她幸福，是因为她最终看到：儿子长大了，懂事了。这种爱相当有深度，也相当能给人平凡中的震撼。

这个片子有很多看点，每个人看多多少少都会有不同的体会，你如果有时间，千万别错过哦。

对了，这部片子最后的片尾曲相当好听，我已经听了N遍了；另外，这部片子对白是德语，如果你碰巧在学德语，也是不错的学习资料。