1，static member

可使用该类对象的空引用来引用该类static member
SomeClass obj = null;
obj.staticMethod();
obj.staticData = 1;

用对象引用静态成员是不被推荐的，但为什么不像C#那样禁止掉呢？

2，多重继承

面对从多个接口继承而来的签名相同的方法，子类似乎只能提供一份实现，这样语义的正确性是如何保证的呢？C#可以在子类中为从多个接口继承而来的签名相同的方法各提供一份实现

3，局部类、匿名类、接口内部类

语言在设计方面提供的创新的语法设施，唯一的问题是不要滥用

4，混乱的数组

似乎违反了那句“装苹果的篮子不是装水果的篮子”，在需要基类数组的地方可以传递子类数组，丧失了编译期类型安全性，通过运行时异常来避免错误

5，求值顺序

明确规定了从左至右，善莫大焉

6，作用域

局部变量、参数能够屏蔽成员变量
局部变量不能与参数同名
更加局部的变量不能与外围局部变量同名
善莫大焉

7，逗号表达式

没有逗号表达式，for里面那个不算

8，break label

功能强大，代替flag，goto

9，异常

相对于返回错误代码来说，异常就是那个层次的AOP

10，异常声明与返回值的不同待遇

相同的是都不能做为overload的依据，不同的是override时，异常声明可以被放宽为子类，返回值却不能基于同样的理由放宽为子类，即协变

11，类锁与实例锁

互不相干

12，服务端同步与客户端同步

前者主要保护自己的内部数据，后者主要保证调用序列

13，main

Everything has a begin, has an end-------Matrix Revolution
我猜中了开头，却猜不到这结局----仙履奇缘

Java程序以main始，却未必以main终，直到最后一个user线程退出；?假若main启动了一个user线程，该线程又启动了一个，又启动了一个，则虽我之死，有子存焉；子又生孙，孙又生子；子又有子，子又有孙。子子孙孙，无穷匮也

先有鸡还是先有蛋？人的起源，生命的起源到底如何？或许有一天人们追溯到极点，却发现不过是JVM启动了main，世界毁灭时，不过是JVM崩溃了

扯远了，.Net的线程与此类似

14，J2SE 1.5的倒退

静态引入 Static Import
格式化的输出 Formatted Output
格式化的输入 Formatted Input
不定参数 Varargs

简直不敢相信，宁肯学C也不学C++

15，Proxy

当年C++中引入template，只是为了Generic Programming，却无意中发现了其Generative Programming的强大功能；不知道Java中的Proxy最初的意图是什么，却引起了Generative Programming另外一种形式－－AOP的风潮

16，ClassLoader

在程序中开个后门，某个类的字节码从我的个人网站上下载，别被客户发现，以后想起来就改改，呵呵

17，语言、库、平台，模糊的边界

字符串连接操作符“+”，是语言的一部分还是库的一部分？
序列化/反序列化时那个可被虚拟机调用的私有的方法，是语言的一部分还是库的一部分？
SoftRefrence、WeakRefrence等被虚拟机用来处理对象引用这样的核心语言特性的类，是语言的一部分还是库的一部分？

Java不是平台无关的，它本身就是个平台；不是说它不好，只是和传统的语言有这样一些区别

18，@deprecated

比起XDoclet等工具，.Net的属性等特性，它更早的触动了Java的神经：注释居然影响了编译器的行为！总算发展出了带有标注的Java

19，override的不同理念

Java/C#：只要访问权限允许，就可以调用重写的方法，不管子类对象构造出来没有
C++：只要子类对象构造出来了，就可以调用重写的方法，不管访问权限

造成的后果就是：

Java/C#：在基类构造函数里调用方法，只要子类有权限覆写，就会调到子类的实现
C++：在基类构造函数/析构函数里调用的方法永远都是基类的实现，不会调到子类；在其它方法里面永远都是调到子类的覆写实现，不管是不是private

20，IO

字节是没语义的，因此叫Stream
字符是有语义的，因此叫Reader与Writer

需要将没语义的适配为有语义的，叫InputStreamReader，OutputStreamWriter
实用的，叫DataXXX，对象序列化的，叫ObjectXXX

21，java.io.File

放错了地方，实际是文件系统的抽象，跟IO没什么太大关系，应放到系统包里，跟Thread之类并列

22，Collections

一般的设计原则是子类重写方法的前置条件应弱于父类方法，但Collection及其子类适时的没有遵守这个原则，以此证明了任何原则都有适用范围； Collection的设计目的是尽可能通用，而不是运行时的多态，你仍然需要选择合适的具体的数据结构，尽管它有时只是通过Collection接口来引用

23，Iterator

不同于STL，Iterator提供了内部安全的Remove()，部分还提供了Add()；但遍历终归是不安全的，又一次不同于STL，Iterator自己能感知外界变化，抛出异常来自我保护，而不是产生未定义行为

24，Timer()，Timer(true)

最常用的却不是最方便的，不得不记住参数；可以用两个创建方法，可以用两个子类，就算用参数，也应该用枚举代替布尔，噢，忘了1.5之前没有枚举，那就静态常量吧，new Timer(Timer.DEAMON)和new Timer(true)，哪个更清晰？

25，脆弱的private

除了序列化/反序列化时访问权限被平台破坏，在缺省安全设置下，Class.newInstance()也能够构建ctor声明为private的类的实例，带来的效果就是，希望强迫客户代码使用IoC原则的开发者，可用放心的将bean的ctor声明为private了

即使你听够了有关Google的事，你还是可以从书中找到这家公司重量级的新信息。

　　“混乱的Google！”，最新一期的《财富》如此评价人们心目中的搜索英雄。数年来，几乎所有媒体都不忘从报道Google的新闻中来赢取更多的关注，对于Google的评价更是五花八门，糟糕、丑恶、顽固、自大、贪婪、还有恶魔……可笑的是，用这些奇怪的词作为Google的前缀竟然很难产生一种贬义和讽刺，用“恶”来形容“不作恶”的 Google，多么滑稽而可笑。

　　或许是人们对Google的期望过高，或许是过多关于Google的消息让人们开始麻木，亦或是如此一个“游乐园”式的公司与其1400亿美元的市值相去甚远，总之，除了对它敬若神明的用户们，Google似乎很难成为一个让人100%满意的公司。上市前，Google的神秘令人着迷，上市后，Google一如既往的神秘引来的是质疑和狂躁，这就是Google的魅力，有人对它恨之入骨，有人对它如痴如醉。惟一的原因只能是，你还不了解Google，或者更直白地说，你根本无法完全了解Google。

　　无论它是否是你的默认首页或是搜索引擎，你都不得不承认，仅仅只有不足10年发展史的Google确实拥有太多太多的故事为人们津津乐道，为什么网络泡沫中Google丝毫无损，甚而壮大？为什么Google的股价可以突破每股400美元而毫不费力？为什么Google的市值能够超过那些前辈级公司、世界500强企业，甚至是一些国家的股市市值？Google凭什么吸引全球最优秀的人才而成为硅谷每平方米博士最密集的公司？

　　只要有心人存在于这个世界上，就没有永远的秘密可言，这场关于Google的调查因戴维·怀斯（David A. Vise）和马克·马西德（Mark Maiseed）的介入而进入了更高境界，同Google的出人意料一样，他们俩不是来自更关心Google股价和内幕的《华尔街日报》，而是相对传统和更会讲故事的《华盛顿邮报》。一部《The Google Story》的诞生就这样顺理成章，尽管这本书拥有一个更具煽动性的中文名《撬动地球的Google》，但更多的老兵还是喜欢原汁原味地称它为《Google故事》，就像两位创使人布尔和佩奇所推崇的“小就是大”，讲故事远比说教和唱高调更得人心。

　　“如果你发现书中的很多故事你已经了解，那这本书就不应该出现在这个世界上”，怀斯自信他讲的Google故事一定是你没有听过的，至少也是你不熟悉的。“如果你要的是情节，而不是网页评比的统计数字，《The Google Story》是你目前为止可以获得的最佳选择”，如果这本书不够精彩，《巴尔的摩太阳报》的评价也没有必要这么夸张。显然，对150多人的采访、录像、录音、笔记、公共和私人文件、网上贴子和电子邮件的收集让这本书的内容相当丰满，他们来自Google现在和过去的投资人、客户、竞争对手，有Google 的董事和经理，也有美国在线、微软、雅虎的高层。故事从布尔遇到佩奇的大学开始，采访从华盛顿向硅谷、加利福尼亚等美国城市及欧洲、南美洲、以色列、西非延伸，在时间和空间的推移中，我们亲身感觉到Google的成长和全球化扩张的步伐是这样地稳且快，转眼之间，Google的烙印就打在了整个地球的每一个角落上，兴奋点就在其中的每一处细节中。

　　了解一个公司，就必须要了解这个公司的管理者，为什么Google总是难以琢磨，因为两个20多岁的大男孩做的事是没有任何道理而言的。迄今为止，最深入的Google报道恐怕不是来自《MIT技术评论》、《纽约时报》，或是《财富》和《福布斯》。用纯技术和商业眼光来打量Google和两个男孩，当然只有一头雾水。这点，怀斯和马西德比他们聪明得多，他们大量地参考了《纽约客》专栏作家约翰·海勒曼（John Heilemann）的《Google中心游记》，深深体会到那种革命性的、憎恨邪恶、钱包满满而且可能会自我毁灭的微妙感觉。他们更仔细地描述出这两个男孩坐客充斥着赤裸和情欲图片的《花花公子》时那种近乎于意淫式的自我陶醉，甚至将这篇《花花公子》的专访提交给证券交易委员会的文件中，作为一种象征着男人成熟的荣耀。当然，更多的商业文化内涵还是属于《新闻周刊》、《金融时报》、《经济学人》或是《连线》，现实中，Google需要被神化，商业领域中更需要既盖茨之后的另类偶像。

　　不会再有人愚蠢地向读者去介绍Google了，怀斯并不是偏执狂，但有一点很明确，无论是褒还是贬，到今天还不知道Google的人，也无需再搭理他。他不希望自己是Google的传教士，向人们宣传Google的各种优点，把布尔、佩奇、埃里克·施米特、或是李开复等热门人物捧在天上、挂在嘴边，“即使你听够了有关Google的事，你还是可以从中找到这家重量级公司的新信息”，怀斯和马西德对《休斯敦纪事报》的评价相当欣赏，并把这段话印在了书的封底上当作招牌。显然，他们的目的是希望通过这本《Google故事》改变Google那种过于神秘的气质。很多事情其实并不神秘，只是你不知道罢了。

　　Google的成功是运气吗？别以为布尔和佩奇是一帆风顺的暴发户，如果当初他们真的顺利地将Google的搜索技术卖给了雅虎、美国在线或是已经消失的搜索技术前辈AltaVista，谁还会知道Google是个什么东西，要知道，当初布尔定的价格只是他心中的“天价”100万美元，无人问津的结果只能是两个技术傻小子自己成立公司用它赚点小钱，他们真的是有眼光的天才吗？为什么盖茨那么憎恨Google，“如果他们专做搜索，那与我无关，但Google也在做软件，我不可能装看不见”，而事实上，Google不但在做软件，还从来没有放弃过对硬件的野心，在Google设在硅谷的太空时代总部Googleplex中，有许多戒备森严的研究室，答案就藏在这里。单纯的人是无法在商业竞争中胜出的，布尔和佩奇的父母都是技术界的名人，一层一层关系让人呼吸困难。另一个细节是，盖茨大楼是学生时代的佩奇经常出没的地方，特定的时代和敏感的地点，没有一个美国学生不想成为盖茨式的人物。这里没有弗洛伊德式的玄奥，但绝对没有普通人想得那么简单。

　　揭穿秘密不如带着读者去寻找答案，作者从不避讳谈起书中的一些资料完全来源于互联网，当然包括Google自己的搜索结果。你也许能猜到，Sun公司名字是福坦福大学网络（Stanford University Network）的缩写，也知道Google的名字代表1后面跟着100个“0”，但你绝对想不到，Google的出现完全源于拼写错误，正确的拼写应该是“Googol”，天知道这两个男孩在注册域名时在想些什么。一个奇怪的网站，两个奇怪的男孩，上百名技术和商业天才，和一大群拥护者，这就是 Google。也许某一天，Google将从地球上消失，人们很快就会选择另一个搜索网站来满足信息上的需求，但来自Google的那份感情上的慰藉是一时无法被取代的。

1. SOAP: 与 Web Service 无关

虽然SOAP可能是为了实现Web Service而被发明的，但实际上它可以被用在任何需要交换数据的场合（SOAP is an XML-based communication protocol and encoding format for inter-application communication）

• SOAP本身是语义独立的，基本上只是一个信封，你可以往SOAP Header和SOAP Body里塞任何东西，也没有什么Header元素和Body元素是SOAP本身定义的，除了SOAP Fault

• SOAP也是与数据交换方式，或者说传输方式无关的，HTTP，TCP...；

• SOAP本身也是无状态，单向的；

让我们比较一下SOAP和现实生活中的信封：

• 信封只是一个壳，但必不可少，其作用就是让接收者一看就知道是一封信，而不是一束花.(SOAP Envelop元素必不可少)

• 信封对里面的信件内容一无所知，它也没规定里面必须是情书或者工资单. (SOAP 可以包裹任何内容)

• 信件可以由信封包着，交给邮局送达，也可以由熟人顺路带过去. (SOAP 与传输方式无关，HTTP, JMS, SMTP...)

• 信件接收者可以选择回信，也可以不回. (SOAP 是单向的)

是的，就像<<Web Service Security>>作者的比喻，SOAP是应用程序间的电子邮件

正是由于SOAP的这种灵活性，许多新的规范都在SOAP的基础上进行扩展和定制，像WS-Security, WS-Addressing等，无非就是定义了几个标准化的SOAP Header或SOAP Body元素

2. WSDL: 与 Runtime 无关

WSDL是Web Service的静态描述信息，主要是用于在客户程序的编码设计阶段告诉客户程序Web Service的信息，一旦客户程序在设计阶段获得了足够的信息，运行时根本不需要什么WSDL

或许某种情况下运行时需要WSDL的帮助吧，但我没有遇到过，如果你知道，请告诉我

portType其实就是Web服务的接口，但这个名字实在不直观，尤其对非英语国家的人来说，新版本的WSDL规范已经将portType改名为了 “Interface”

3. WSDL-SOAP Binding Style

就是所谓RPC与Document或者Wrapped，Literal与Encoding

先说Literal与Encoding

• Literal 就是不在SOAP消息中表明数据类型，而通过其它方式获知数据类型，这种方式是开发包相关的，没有什么标准；如<x>50< /x>，单从SOAP消息，你无法判断50是数字还是字符串，而具体的类型可以在开发包将SOAP请求映射到具体的Service类时来确定并完成 转换，对于返回值也一样，客户端可已通过SetReturnValueType(...)之类的方法告知开发包自己期待什么类型

• Encoding就是在SOAP消息中携带类型信息，并且依据某种规则将数据编码传递，接收端可以根据类型信息和编码规则完成解码，获得原始数据；如<x xsi:type="xsd:string">50</x>

再看看RPC与Document

• RPC就是按照类似函数调用时所需的信息来组装SOAP消息：操作名作为根元素，参数组成子元素，如：

• Document 就是将SOAP请求和响应，或者说输入输出定义为XML元素，有严格的Schema("document" style means the messages in and out of the service are exactly as they are describe by the XML Schema in the WSDL).如某个Web Service的WSDL片断：

• Wrapped 风格就是定义与操作同名的Element，将参数作为 Child Element；这样操作名又重新回到了SOAP消息中，如WSDL片断：

Document services and wrapped services are similar in that neither uses the SOAP encoding for data; it's just plain old XML schema.

4. UDDI：与 WSDL 无关

虽 然都是描述Web Service的，但UDDI与WSDL各司其责；事实上，UDDI野心太大，定义了很多社会性的Attribute，而不局限于技术性的Web服务，如 人工电话服务信息和传真服务信息都可以注册到UDDI中，描述性的东西很多（descriptive information ）一些overviewURL 也都推荐指向文档，关于这点，参照目前UDDI的应用情况，我认为UDDI是过度设计了

UDDI 注册表其实是一堆元数据的集合，元元数据...，元数据用tModel来表达，可以有不同的分类，通过tModel key来引用；当你试图用字符串表达什么东西时，你最好看看是否已经有了对应的tModel，有的话你就需要用对该tModel的引用来代替字符串，如在 UDDI中表达一个Web Service的PortType时，你不应该在某处用字符串“PortType”来表明这是一个Port Type，你应该引用预定义的PortType tModel来表明：

Web Service与UDDI的关系类似于COM组件服务与Windows注册表的关系，其实它们可以看作是同一个概念的不同发展阶段或不同实现

而UDDI直观的比喻可以是图书馆卡片索引，在我上中学的时候，图书馆没有计算机供读者查询图书信息，只有一柜一柜一橱一橱的索引卡片，记录了图书信息，如作者出版社等，当然最重要的是它在书库里的位置，第几排第几格

分 类体系在UDDI中占很大比重，不同的Category如传输协议，命名空间，WSDL Type等，每一个Entity或tModel都可以具有多个分类属性，比如上面的StockQuotePortType tModel,按名称空间来分，它属于http://example.com/stockquote/，按WSDL Type来分，它属于portType；BindingTemplate Entity还具有传输协议的分类，值可以是HTTP或SMTP之类

分类体系在现实生活中随处可见，比如说同一个人，按性别分是mm，按婚否分是未婚，按政治面貌分是刁民；图书馆的索引卡片上也随处可见，按出版社分是三联，按题材分是小说，按风格分是后现代等等

5. UDDI：与WSDL 有关

毕竟都是描述WebService的，还是有部分内容有关系的，于是有了WSDL到UDDI的映射，这样某些工具就可以自动将WebService注册到UDDI中

大 体上就是<portType>和<binding>作为tModel映射到UDDI中，<service>映射为 <businessService>, <port>映射为<bindingTemplate>

6. JAX-RPC: 首先是Java,其次才是RPC