JSF 可以让AJAX 不使用JavaScript

【IT168 专稿】很多JSF专家表示，JSF（JavaServer Faces）可以在不需要编写JavaScript代码的情况下开发异步的JavaScript 和 XML应用程序。
　　 在服务器端Java（ServerSide Java）研讨会3月22日的一次会议上，SUN公司的高级工程师Ed Burns说：开发人员可以使用JSF开发出企业级的AJAX应用程序，这些应用经过了充分的行业证明，具有良好的健壮性，可靠性，易用性和伸缩性。
　　 Ed Burn还表示：“可以通过不同的方式来使用JSF和AJAX。 其中一种方式是同时使用JSF和Project Dynamic Faces 或DynaFaces。 通过这种方式，使用者不需要JavaScript的知识，如果使用者喜欢使用JavaScript还可以构建功能更加强大的应用程序。另一种方法是使用AJAX支持的JSF组件，这种方法只需要有对AJAX很少的知识就可以。另外开发人员还可以只使用AJAX或使用一种AJAX框架。” 　　B 　　 urns说：“除了Project Dynamic Faces，还有其他的方式来同时使用JSF和AJAX，其中包括使用ICEsoft公司的 ICEfaces, Ajax2JSF, AjaxAnywhere 和Backbase。”Google公司的Adam Bosworth可以告诉你为什么AJAX在经历失败后又会成功。（点击此连接到相应页面）。
　　 Burns还说：“早在AJAX还不是如此强大之前，JSF的面向对象设计已经为JSF可以在AJAX中使用做了准备。JSF的如下主要特性使得它对于AJAX来说是友好的，其中包括灵活的可扩展组件模型，明确的请求处理生命周期（Request Processing Lifecycle）和一个灵活的可扩展渲染模型。
　　 Burns 说,AJAX的成功在于其具有的如下理念：JavaScript对页面的开发人员来说透明，但却可以被组件开发者看到；通过状态管理使客户端和服务器端轻松保持同步等。使用JSF和AJAX还可以解决跨浏览器的问题。同时，Project Dynamic Faces将AJAX强大的功能引入到已有的和未来的利用JSF开发的应用。
在2007年于纽约召开的AJAX World大会上，位于康涅狄格州斯坦福德的Virtua公司首席咨询师Kito Mann做了一个名为“看啊，不用JavaScript也可以（Look Ma, No JavaScript）”的讲演，表达了和Burns一样的观点。Mann讲演的主旨是：“使用JSF，可以在不编写任何JavaScript代码的情况下构建应用程序。” Mann说，JSF是针对于JAVA的一种标准的web用户界面框架，其规范包括服务器端用户界面组件，事件模型，一组基本的用户界面组件和基本的应用结构。Mann还是JSFCentral.com的创建者之一。JSFCentral.com是一个由使用JSF技术的开发人员，架构师和经理组成的社区。另外，他还是Java 社区Process' JSF专家组的成员之一。 曼恩说，JSF还提供广泛的工具支持和用RAD(快速应用开发)模式的方法去开发Java Web。此外, JSF是建立在Servlet API之上的，并且促进了第三方用户界面组件市场的发展,他说。 总体来说,“JSF提供透明的AJAX支持，”曼恩说。"我们的想法就是JSF编程模型能与AJAX一起工作。" 有多种支持JSF的IDES(集成开发环境),包括Sun的Java Studio Creator，BEA 的Workshop Studio，Oracle的 JDeveloper 和 Exadel Studio Pro (现在在JBoss umbrella旗下)，曼恩说。 而且，JSF架构加上AJAX支持很容易，他说。 事实上，曼恩说JSF有三个主要的AJAX集成策略。
一是把AJAX支持加到现有组件中，二是把AJAX支持直接集成到JSF组件中，三是对现有AJAX控件封装成一个JSF组件，曼恩说。 用在第一种方法中的技术包括Exadel的Ajax4JSF，Ideo技术的开源AjaxAnywhere offering和Sun的DynaFaces,，曼恩说。
支持AJAX直接集成到JSF组件的产品或技术包括Simplica的ECruiser，Infragistics的NetAdvantage，Sun的Project Woodstock，和来自ICEsoft, Backbase and Exadel的技术，曼恩说。 封装现有的AJAX控件到JSF中，两个主要的选择是Sun’s jMaki和Dojo Foundation’s Dojo Faces，他说。

JDK早期版本中使用Java 5语言特性

作者: Brian Goetz, 　出处:developerWorks 中国,　责任编辑: 叶江,　

2007-03-27 09:12

　　本文将演示如何在 JDK 早期版本中使用 Java 5 的语言特性……

　　Java 5 添加了许多强大的语言特性：泛型、枚举、注释、自动装箱和增强的 for 循环。但是，许多工作组仍然被绑定在 JDK 1.4 或以前的版本上，可能需要花些时间才能使用新版本。但是，这些开发人员仍然可以使用这些功能强大的语言特性，同时在 JVM 早期版本上部署。

　　随着最新的 Java 6.0 的发布，您可能认为 Java 5 的语言特性是 “旧的新特性”。但是即使在现在，当我询问开发人员在开发时使用的 Java 平台的版本时，通常只有一半人在使用 Java 5 —— 另一半则只能表示羡慕。他们非常希望使用 Java 5 中添加的语言特性，例如泛型和注释，但仍有许多因素妨碍他们这样做。

　　不能利用 Java 5 特性的开发人员包括那些开发组件、库或应用程序框架的开发人员。因为他们的客户可能仍然在使用 JDK 1.4 或以前的版本，并且 JDK 1.4 或以前的 JVM 不能装载用 Java 5 编译的类，所以使用 Java 5 语言特性会把他们的客户基数限制在已经迁移到 Java 5 的公司。

　　另一类经常避免使用 Java 5 的开发人员是使用 Java EE 的开发人员。许多开发团队不愿在 Java EE 1.4 及以前的版本上使用 Java 5，因为担心其应用服务器的厂商不支持 Java 5。这些开发人员要迁移到 Java EE 5 可能还有待时日。除了 Java EE 5 和 Java SE 5 规范之间的滞后，商业 Java EE 5 容器没有必要在规范刚刚制定好就能使用，企业也没有必要在应用服务器出现下一个版本时就立即升级，而且在升级应用服务器之后，可能还需要花些时间在新平台 上验证其应用程序。

　　Java 5 语言特性的实现

　　Java 5 中添加的语言特性 —— 泛型、枚举、注释、自动装箱和增强的 for 循环 —— 不需要修改 JVM 的指令集，几乎全部是在静态编译器(javac)和类库中实现的。当编译器遇到使用泛型的情况时，会试图检查是否保证了类型安全(如果不能检查，会发出 “unchecked cast”)，然后发出字节码，生成的字节码与等价的非泛型代码、类型强制转换所生成的字节码相同。类似的，自动装箱和增强的 for 循环仅仅是等价的 “语法糖”，只是更复杂的语法和枚举被编译到普通的类中。

　　在理论上，可以采用 javac 生成的类文件，在早期的 JVM 中装入它们，这实际上正是 JSR 14(负责泛型的 Java Community Process 工作组)的成立目的。但是，其他问题(例如注释的保持)迫使类文件的版本在 Java 1.4 和 Java 5 之间变化，因此妨碍了早期 JVM 中装入用 Java 5 编译的代码。而且，在 Java 5 中添加的有些语言特性依赖于 Java 5 库。如果用 javac -target 1.5 编译类，并试图将它装入早期 JVM 中，就会得到 UnsupportedClassVersionError，因为 -target 1.5 选项生成的类的类文件版本是 49，而 JDK 1.4 只支持版最大为 48 的类文件版本。

　　for-each 循环

　　增强的 for 循环有时叫做 for-each 循环，编译器编译它的时候，情形与程序员提供旧式 for 循环一样。for-each 循环能够迭代数组或集合中的元素。清单 1 显示了用 for-each 在集合上迭代的语法：

　　清单 1. for-each 循环

Collection fooCollection = ... 　　for (Foo f : fooCollection) { 　　doSomething(f); 　　}

　　编译器把这个代码转换成等价的基于迭代器的循环，如清单 2 所示：

　　清单 2. 清单 1 基于迭代器的等价循环

for (Iterator iter=f.iterator(); f.hasNext();) { 　　Foo f = iter.next(); 　　doSomething(f); 　　}

　　编译器如何知道提供的参数有一个 iterator() 方法呢? javac 编译器的设计者可能已经内置了对集合框架的理解，但是这种方法有些不必要的限制。所以，创建了一个新的接口 java.lang.Iterable(请参阅清单 3 )，并翻新集合类使其实现 Iterable 接口。这样，不是在核心集合框架上构建的容器类也能利用新的 for-each 循环。但是这样做会形成对 Java 5 类库的依赖，因为在 JDK 1.4 中没有 Iterable。

　　清单 3. Iterable 接口

　　public interface Iterable {
　　Iterator iterator();
　　}
枚举和自动装箱

　　正像 for-each 循环一样，枚举也要求来自类库的支持。当编译器遇到枚举类型时，生成的类将扩展库类 java.lang.Enum。但是，同 Iterable 一样，在 JDK 1.4 类库中也没有 Enum 类。

　　类似的，自动装箱依赖于添加到原始包装器类(例如 Integer)的 valueOf() 方法。当装箱需要从 int 转换到 Integer 时，编译器并不调用 new Integer(int)，而是生成对 Integer.valueOf(int) 的调用。valueOf() 方法的实现利用 享元(flyweight)模式 为常用的整数值缓存 Integer 对象(Java 6 的实现缓存从 -128 到 127 的整数)，由于消除了冗余的实例化，可能会提高性能。而且，就像 Iterable 和 Enum 一样，valueOf() 方法在 JDK 1.4 类库中也不存在。

　　变长参数

　　当编译器遇到用变长参数列表定义的方法时，会把其转换成包含正确组件类型数组的方法;当编译器遇到带有变长参数列表方法的调用时，就把参数装进数组。

　　注释

　　定义了注释的之后，可以用 @Retention 对它进行注释，它可以决定编译器对使用这个注释的类、方法或字段执行什么处理。已经定义的保持策略有 SOURCE (在编译时舍弃注释数据)、CLASS (在类文件中记录注释)或 RUNTIME (在类文件中记录注释，并在运行时保留注释，这样就可以反射地访问它们了)。

　　其他的库依赖关系

　　在 Java 5 之前，当编译器遇到尝试连接两个字符串的情况时，会使用帮助器类 StringBuffer 执行连接。在 Java 5 及以后的版本中，转而调用新的 StringBuilder 类，JDK 1.4 及以前的类库中不存在该类。

　　访问 Java 5 特性

　　因为语言特性对库支持的依赖，即使使用 Java 5 编译器生成的类文件能够装入早期 JVM 版本，执行也会因为类装入错误而失败。但是，通过对字节码进行适当转换，仍有可能解决这些问题，因为这些遗漏的类并不包含实际的新功能。

　　JSR 14

　　在 Java 泛型规范(以及其他 Java 5 新添加的语言特性)的开发期间，在 javac 编译器中添加了试验性的支持，以便让它能使用 Java 5 的语言特性，并生成能在 Java 1.4 JVM 上运行的字节码。虽然这些特性不受支持(甚至是文档)，但许多开源项目都使用了它们，使得开发人员能使用 Java 5 语言特性编码，并生成能在早期 JVM 上使用的 JAR 文件。而且，既然 javac 是开源的，那么这个特性有可能得到第三方的支持。要激活这些特性，可以用 -source 1.5 和 -target jsr14 选项调用 javac。

　　javac 的 JSR 14 目标模式使编译器生成与 Java 5 语言特性对应的 JDK 1.4 兼容字节码：

• 　　泛型和变长参数：编译器在泛型出现的地方插入的强制转换不依赖类库，所以能够在 Java 5 之前的 JVM 上很好地执行。类似的，编译器在出现变长参数列表的地方生成的代码也不依赖类库。
• 　　for-each 循环：当迭代数组时，编译器生成归纳变量和标准的数组迭代语法。当在 Collection 上迭代时，编译器生成标准的基于迭代器的语法。当在非集合的 Iterable 上迭代时，编译器生成错误。
• 　　自动装箱：编译器不生成对包装器类的 valueOf() 方法的调用，而是生成对构造函数的调用。
• 　　字符串连接：javac 的 JSR 14 目标模式使编译器生成对 StringBuffer 的调用而不是对 StringBuilder 的调用。
• 　　枚举：javac JSR 14 目标模式对枚举没有特殊支持。尝试使用枚举的代码会失败，在寻找 java.lang.Enum 基类时出现 NoClassDefFoundError。

　　使用 JSR 14 目标模式允许在 “简易” 情况下编写使用泛型、自动装箱和 for-each 循环的代码，这对多数项目来说可能足够了。这很方便，如果不支持的话，编译器会一次生成基本兼容的字节码。

……

Google的巨额财富之困

天极ChinaByte 特稿(杨剑) “Google的确主动积极，而且出手迅速。”拥有计算机科学博士学位，服务器软件Jigsaw的开发人贝尔德-史密斯说。

　　2005年6月，身为工程师的贝尔德-史密斯(Anselm Baird-Smith)正在考虑是否离开eBay的时候，接到了Google的电话。没过几天，Google的高层管理人员就对他进行了面试，摊出一份 颇有诱惑力的合同：六位数的年薪加限制性股票。而Google首席执行长施密特(Eric Schmidt)甚至亲自打来电话，敦促史密斯尽快倒戈。Google向贝尔德-史密斯开出的条件促使eBay提出了用现金奖励换取贝尔德-史密斯留任的 做法。虽然，史密斯最后拒绝了Google，但Google在人才方面的“狼子野心”已经昭然若揭了。

　　BEA的亚当博斯沃思(Adam Bosworth)、微软公司的李开复、eBay的路易斯莫尼尔(Louis Monier)则没有抵挡住Google的金元攻势，Google甚至从MCI挖来了有互联网之父美誉的文顿塞弗(Vinton Cerf)。

　　Google的人才“挖角”让它树敌不少，微软首席执行长史蒂夫·鲍尔默甚至为此大发雷霆，公开指责Google的行为。但Google显然不 在乎这些，迅速增长的财富让Google有足够的实力应付这些麻烦。当然，Google吸引人才的除了金钱可能还有其它原因，比如轻松自由的工作氛围。

　　但是，现在或者未来Google却将面临一些麻烦。

　　麻烦的根源正是Google大肆“挖角”的保障，那些巨额的财富与当初大手大脚“利诱”人才的行为。

　　美国《圣荷西信使报》报道，在即将迎来上市三周年之际，Google面临着巨大成功所带来的棘手难题——早期创业员工的流失。随着最后一笔期权行权期的临近，一批创业元老即将成为百万富翁，并随时可能选择离开。

　　《圣荷西信使报》看到的可能只是一个即将来到的麻烦，实际上，几乎所有被Google“利诱”来的人才都面临着这个问题。

　　“当工作已经缺乏乐趣，而你又拥有可以享受乐趣的财富，你会怎么选择?”为Google最赚钱的业务“Adwords”命名的道格·爱德华兹(Doug Edwards)显然具有权威的发言权，他用实际行动为大多数面临抉择人作出了表率，那就是辞职。

　　另外一种情况是，无论Google的工作环境怎样自由，一些人还是喜欢自己掌控一切的感觉。“我进Google只为了一个目的，我再也不想为别 人拼命工作了，除了为自己。”曾经为Google员工奉献了许多美味佳肴的大厨查理·艾尔斯(Charlie Ayers)在执行完期权后就离职了。现在他正计划在加州帕洛阿尔托市(Palo Alto)开一家餐馆，自己做自己的老板。

　　Google可能还要继续因为自己的巨额财富与“慷慨”付出代价，因为，它的人才战略让它的员工几乎都能成为百万富翁，前提是执行完Google给予他们的期权。

　　虽然，目前大多数执行完首批期权的员工仍然留在Google，但实际上，他们现在拥有的财富已经够他们挥霍一辈子了。

　　看银行户头上的数字跳跃性的增长让人非常享受。但是当财富积累到只是一个数字，又有多少人禁得住把虚拟的数字变为实际享受的诱惑呢?

　　后记：“铁打的营盘流水的兵”，每个企业都面临人才流动的问题。也许这对Google来说不是问题，因为它可以继续用它的财富吸引新的人才。只 不过它的慷慨也许让它在老员工上损失更大一些罢了。其实，不止Google，中国的百度同样也将面临这个问题，谁让他们的员工财富增长的太快了呢?

中国加入Google全球开发者日活动

2007年4月12日 （北京）－Google（谷歌）宣布，公司将于2007年5月31日在全 球10个国家的分支机构举办“开发者日”活动。这次全球活动的主题是“Google 开发者日：为你的网站添砖加瓦”。活动期间，Google（谷歌）将就API和开发者工具举行研讨会、主旨演讲和即兴讨论。整个活动从悉尼拉开序幕（澳大 利亚东部标准时间5月31日上午9时）， 27个小时之后，在Google（谷歌）总部山景城落幕（美国太平洋标准时间5月31日晚7时）。同时举办这次活动的国家还包括中国北京、巴西圣保罗、英 国伦敦、法国巴黎、西班牙马德里、德国汉堡、日本东京、和俄罗斯莫斯科。　

　　Google（谷歌）搜索产品和用户体验副总裁Marissa Mayer女士说：“我们希望为开发者提供一次相互联谊、学习最新技术以及向Google开发者产品团队提出疑问并得到解答的机会。对Google而言， 这也是一次从开发者群体中获取反馈、寻求进一步改善开发者产品途径的机会。”　　

　　在中国，Google（谷歌）是第一次举办“开发者日”的活动。出全球共有内容关于开发者与Google（谷歌）现有产品的整合扩展外，中国还将增加关于Linux和开源的专门话题。

　　“Google（谷歌）开发者日”上，Google（谷歌）中国将讲解Google的API和各种工具，帮助开发者提升各自产品的效率，更好 地和Google结合，惠泽千百万的用户。Google（谷歌）中国希望能够通过自己的力量使中国的开发者在网络上开发出数以千计的新应用软件，无论这些 应用软件是迎合了大众市场的需求，还只是仅仅解决了一个小众的问题。
　
　　另一方面，Google（谷歌）是开源和Linux操作系统的受益者；Google也举办了像暑期编程大赛、在 code.google.com上发布开源项目这样的活动，回馈开源社区和Linux社区。在中国，越来越多来自不同组织的开源开发者们渴望与开源的领袖 和专家进行面对面的沟通。正因为此，Google（谷歌）将在“开发者日”上介绍开源文化与技术，满足来自技术性用户的迫切需求。

　　今年5月参加Google（谷歌）中国“开发者日”的演讲嘉宾有Google Geo API项目的工程师安兴华、Google Data API项目工程师杨骏、Guice项目经理Bob Lee、Google（谷歌）软件工程师周欣、Python语言发明人Guido Van Rossum、Google（谷歌）开源项目工程师 Jon Trowbridge和开源项目SCIM作者

　　Google（谷歌）软件工程师苏哲。他们演讲的主题包括：“Google Geo API”、“Google Data API”、“用Guice开发Java应用”、“Google Web Toolkit”、“Python语言”、“Google与开源”以及“Linux平台的国际化和本地化编程”。

　　Google（谷歌）中国区总裁李开复表示：“Google（谷歌）中国要有长期的发展，要给Google（谷歌）的中国用户们带来惊喜，不 但需要Google（谷歌）中国工程师们的努力，更要仰仗中国杰出的开发者们。我们欢迎技术精英能在Google（谷歌）开放的平台上，利用Google API和其它开发工具为中国互联网带来创新，让中国用户享受到更先进的产品和应用。”　　

　　关于“Google（谷歌）开发者日”的报名注册以及其他相关信息，请访问“Google（谷歌）开发者日”网站：　　

　　http://www.google.com/events/developerday/zh_CN/details.html

Google在中国的尴尬两年 误把国际化当成本土化

http://www.jrj.com　 2007年04月14日 00:36 财经时报

【评论】【字体：大 中 小】 【页面调色版 】

　　本报记者 李国训

　　“Google在中国的做法，使它在美国及欧洲的声誉受到损害。”

　　四月的北京，春意正浓。但对于Google中国（谷歌）掌门人李开复来说，却是一个十分艰难的时期。

　　这位46岁的中年男人此前在苹果电脑、SGI、微软等知名公司的职业生涯可谓一帆风顺，但在Google却意外遭遇了多次危机：最早一 次是在两年前，他因跳槽至Google而与微软打了长达半年的官司；而这一次，他则因“词库门”事件背上了“剽窃”的罪名，过去两年累积的个人声望也由此 受到影响。

　　更不幸的是，最近几日，美国贸易代表计划向世贸组织就中国对美国公司拥有的版权保护不力提出申诉的消息正传得沸沸扬扬，Google这个美国公司剽窃中国公司技术专利的事件，也很快引起了美联社、路透社等众多海外媒体的高度关注。

　　李开复的个人遭遇，也被人视为Google在华600多天的黯淡轨迹的一个缩影。从2005年轰轰烈烈进入中国至今，Google耗资 甚多，但收获惨淡，其在国内搜索市场的份额从33％惨跌到20％，竞争对手百度则从43.4％飙升至55.3％。这样的尴尬结局着实富有讽刺意味。

　　Google在中国的尴尬两年，已令Google创始人赛吉·布林感到懊悔不已。不久前他说：“Google在中国的做法，使它在美国及欧洲的声誉受到损害。”“词库门”事件的频频升级，想必也坚定了他的判断。

　　前后600天，李开复和他的谷歌到底经历了哪些事情，竟然走到了难以收场的地步？Google在中国难道要重蹈雅虎、Ebay等国外公司类似的命运？Google如何避免“中国式失败”？种种话题，也引起了业内的激烈争论。

　　“词库门”事件始末

　　一切都要从“词库门”事件说起。这一事件不仅激发了搜狐与Google两个公司之间的口水战，也暴露了谷歌各方面深层次的危机。

　　导火索源于4月4日。当日上午，谷歌在京发布了输入法产品。以往Google发布新产品大多比较低调，但这次却不同，李开复采取的是“高调曝光”的策略。大概在他看来，谷歌输入法显然是本土化战略中的重要一环。

　　但事件的发展很快就出乎了李的意料。当日下午，业内几大论坛就出现了关于Google涉嫌抄袭搜狗输入法词库的质疑。

　　早在一年前，搜狐就推出了搜狗输入法产品。质疑者发现，谷歌输入法词库不仅与搜狗输入法高度重合，而且完全是抄袭搜狐输入法，证据确凿，谷歌无法自圆其说。

　　以独特创新而闻名全球的Google，居然会抄袭一家中国公司的产品！这样的消息无疑振聋发聩。很快，各大网络媒体以及众多博客就出现 了质疑Google的声音，一些Gfans（Google爱好者）则奋力反击。一时间，互联网硝烟弥漫，网民与网民之间，搜狐与谷歌之间的口水战由此揭 开。

　　随即，谷歌通过自己的网络“黑板报”发出一份文字声明，承认词库确实包含了一些非Google的数据源，并向用户及搜狐公司等表示歉意。但这种“害羞”的道歉并没有得到搜狐的原谅。

　　4月8日，搜狐正式发表公开声明，谴责Google盗用其开发的搜狗拼音输入法词库的“不道德行为”，要求Google立即停止这一行为，并声称谷歌道歉缺乏诚意，要求保留采取进一步行动的权利。

　　4月9日，搜狐公司CEO张朝阳更明确提出：谷歌不仅盗用了搜狐的词库，更剽窃了搜狐将搜索与输入法结合的创意，谷歌必须停止输入法产品的下载服务。

　　在整个口水战的过程中，一些意外插曲也让谷歌的名声进一步蒙羞。知名博客王小峰（按摩乳）提及谷歌公关公司和他接触的细节，令许多网民吃惊不已。随后更有爆料者称，谷歌为了请奥美公司进行危机公关，耗资达120万元。

　　由此导致的恶劣影响可想而知。Google在国内的公关形象一直被坊间形容成“无比贞烈”，而在“词库门”后，这一公关形象已荡然无存。

　　这一事件也折射出了谷歌的众多管理问题：输入法产品从立项到推出历经了很长的一段时间，为何直接盗用竞争对手词库的事情，上层却毫不知情？谷歌发布这款本无创意的跟风产品，为何会选择高调方式，这无疑把自己推向了舆论的风口浪尖。

　　更有舆论指出，李开复在谷歌的600多天，仅仅是忙于经营个人品牌，而对搜索业务很少过问，甚至对搜索了解甚少。因为这一年来，李开复忙于在各个高校巡出演讲，但谷歌的产品却几乎不见改善。

　　本土化“地雷”

　　实际上，在过去两年，谷歌也推出了一些的本土化措施，但遗憾的是，这些措施也和谷歌输入法一样，不仅没有使Google在中国获得应有的尊重，反而招来了Gfans们的诸多抱怨。

　　2005年年底，告别官司的李开复决定在中国公司大肆招兵买马。从那时起，他帮助Google中国做了以下几件事：一是在中国启动域名Google.cn，一是给自己取了个中文名字“谷歌”，还有就是推出导航网址，以及最近的输入法产品。

　　但是，这些动作无不遭到了激烈的批评：独立域名被视为Google为应对中国国情而推出阉割版，违背了“不作恶”的原则：“谷歌”的名字更是被Gfans们千夫所指；模仿hao123推出的导航网站草草收场；而输入法产品则倒在了搜狐的脚下。

　　这期间，谷歌也做了另外一些事情。比如投资国内最大的下载网站迅雷，与中国移动签订合作拓展无线互联网搜索市场等。这些事情尽管对长期有益，但由于产品开发进度缓慢，并不能从根本上扭转谷歌在搜索市场的颓势。

　　相比之下，谷歌的竞争对手们的产品却不断推陈出新，而且更有创新味道。百度推出了新闻、博客、视频、虚拟货币等众多新产品，用户黏合度进一步得到提高；雅虎中国经过一年震荡后也推出了“百业窗”等多种产品；搜狗推出的输入法也使其获得颇高的美誉度。

　　而Google在华两年最大的“成绩”，就是让国内信徒们的梦想幻灭。甚至连业内知名博客洪波最近也私下称，他信仰的是美国的Google，而绝不是中国的谷歌。

　　“本土化，应该是在了解本土用户消费心理的基础上进行的创新服务，而不仅仅是模仿。个人认为Google在对本土用户的了解方面还有很大距离。”4月10日，塞迪顾问分析师常燕杰接受《财经时报》采访时，对谷歌过去两年本土化战略作出了消极的评价。

　　更有业内人士认为，谷歌最大的失败是误把国际化当成了本土化。李开复来到中国，也把美国式的松散管理带入中国，但这种美国文化在中国其实行不通。否则就很难理解，为何在过去600多天内，谷歌几乎没有推出一项像样的产品。

　　根源在于战略摇摆

　　4月10日，易观国际CEO于扬在接受《财经时报》采访时认为，谷歌在过去600天的总体表现确实很失败。但究其根源，谷歌并非本土化做得不好，而是其品牌及战略摇摆不定导致。

　　于扬认为，由于谷歌是舶来品。因此无论它叫“Google”还是“谷歌”，都很难为国内普通老百姓所接受，谷歌想走草根化路线难度很大，国内三四级城市的网民很难接受。

　　Google的优势在于，它在高端用户心目中享有极高的口碑，Gfans对Google情有独钟。于扬认为，这就注定Google在中 国一开始就面临两难选择：如果继续满足高端用户，那么三四级城市的低端用户就会失去；假如走草根化，满足低端用户的需求，又会伤害高端用户的感情。

　　“谷歌总要牺牲一方。它正确的做法应该是先满足高端用户，在巩固这个市场之后，再逐渐渗透低端市场。”于扬认为，从谷歌中国过去两年的表现来看，它们的做法恰好相反，无论是取名、推网址还是输入法，都更像是争夺低端市场。

　　于扬总结说，谷歌的失败在于，它没有搞清品牌战略和定位问题，因此也没有搞清楚自己的用户群，自然也就难以制定出合适的战略。“战略就是取舍，是决定做什么和不做什么，谷歌却眉毛胡子一把抓，结果就是流量不断地失去，用户喜好度不断下降。”
　　

为何不使用spring、struts2、easyjweb等开源框架

该不该使用各种各样的开源框架,我想这是很多程序员自己也困惑的问题。有的由于对框架的不熟悉，有的是为了程序的优化，还有一些就是觉得开源框架用起来不顺手。
　　关于这个问题，一个在政府做技术主管的朋友这样说：
“1年前,我非常疯狂的喜欢spring velocity webwork struts ....只要是开源的我都忍不住去试着用用。我也在很多项目中使用一些开源技术，其结果是大家怨声多于表扬。其实不是这些技术不好，是我们不会合适去应用。
　　我一直在思考一个问题.是不是我们太热衷于“实现”而忘记了“设计”，我最近几天的思考的问题是：“jsp+javabean”其实也是个好框架，关键在于你如何去应用好设计模式。”

　我认为关键还是要在于我们对这些框架的掌握程度。再好的技术,再好的框架,再简单易用的东西,肯定都有一定的门槛，都存在一定的学习曲线．框架封装了很多底层的东西，尽管其没有限制我们在框架中自己应用一些底层的，但大多数时候我们仍然不知道如何着手．
"大家怨声多于表扬"，之所以这样，我觉得还是他们对框架的核心掌握得不透彻所至．程序员的一个成就感及自豪感，来源于程序员自生对系统、对电脑的一种控 制力．也就是：＂我想让他干嘛就干嘛＂．普通的jsp+javabean，这是最简单的．当然也最容易“控制”．尽管控制他做的事情可能并不强大，写出的 东西有可能难以维护、扩展，但始终是“控制”了。因此，大家很喜欢。
而使用其它框架，很多基础的控制交由了这些框架处理了，尽管这些框架提供了很好的基础平台，好的设计模式供我们使用，但需要我们首先对他有一个比较深入的 理解。否则就谈不上控制，只能照猫画虎般的照着做．一但程序出来的不是我们想要的东西，一但人机交互的结果出现偏差，很多时候就让我们无能为力。在现实 中，不是所有使用的这些框架的人，都熟悉这些框架的原理及内核，都能控制这些框架工作，一但有一些不愉快的尝试，怨声多于表扬也就难免了．

总结志来就是：再好的屠龙刀，只有我们对其非常熟悉、并对其有一种控制能力以后，使用起来才会得心应手，否则更多的人宁愿选择使用自己砍的木棍，虽然威力 差一点，但于少能用他来把一些阿猫阿狗或者是街头混混唬住．当然，也有练到手中没刀，心中有刀的，比如小马哥，此时选择使用什么都无所谓了．