标准是一件坏事情吗？

谁说JSR参与者只有厂商？

GAVIN KING就在 EJB3 JSR 专家组名单上。另外每个 JSR 都有不少以个人名义参加的专家成员，比如MICHAEL YUAN就是以个人名义坐在J2ME 专家组里。

甚至 ROD JOHNSON 本人就是两个 JSR 的专家成员。

呵呵。

JCP/JSR 不是不可以挑战。但是你要有挑战的实力。

人虽然坐进去了，但没有发言权啊，只是一种象征啊，只是一个橡皮图章罢了，最终结果，是他们的hibernate Spring都没有成为一个标准啊。

以下讨论针对“大软件企业”的作用：

JAVA 业界有些同志，尤其是中小应用开发者，往往对 JCP 和平台厂商心存反感。这么说决无轻视中小应用开发者的意思，我的业界朋友里很多就是中小应用开发者或者咨询顾问，我自己业余也写写小应用自娱。的确，对于很多中小型应用，开源平台和框架提供了有效而低成本的一个选择。如果今天我要写个小WEB应用，那么首选绝对不是任何厂家的容器，而是ROR。但是IBM和BEA这样的厂家的地位，至少在短期内还无法被替代。这有几个原因：

1。开源软件无法提供企业级容器的全部功能和性能指标。WEBLOGIC/WEBSPHERE 在JAVA底部，比如 JDK 和 JVM 的优化方面极端积极。JDK、JVM里被认为不够优化或者过于“普遍化”的算法往往被大规模重写。这只是一个例子，在集群等方面，大厂商对算法科研的投入也非常可观。如果有兴趣，不妨在美国专利局的网站上检索一下 IBM，BEA，ORACLE 在算法方面的专利。这种级别的优化，往往是计算机专业硕士博士水平上的操作，因而也就成了大公司的领地。在这方面，开源软件根本无法望其项背。而对于应用软件领域利润最丰厚的大型企业应用领域，这些功能和性能指标至关重要。

2。开源软件提供机构无法提供与大厂商相比的技术和管理过程支持。对于大型企业应用的开发项目，平台厂商的技术支持，和厂商自身的过程管理审计是非常重要的。这些也是开源软件无法进入大企业环境的一个因素。

老板认真讨论，我也顶真一下：

以下讨论针对JCP：

JCP/JSR 里根据参与各方实力的强弱，的确有政治影响力因素，这无法避免，但是并非一定就是坏事。比如，某种程度上我们（作为应用开发者）的确希望大平台厂家有一定的影响力，从而保证技术标准的持续性和一致性。

再者，JCP 不单纯是厂商唱主角，也有很多其他方面的参与，比如大咨询机构，大使用客户，硬件系统厂家，甚至 INTEL，开源组织，业界名人等等。JCP 的运作方式，带有很大的透明度和民主性，而这种开放的民主运作方式所带来的效果是显而易见的。如果你对付过 CORBA，多少会对 CORBA BROKER 恶劣的互操作性有痛彻的体会，这和 JCP/JSR 形成鲜明的对比。

在业界联盟框架内，各厂商之间的既竞争又合作的这种辨证关系非常有意思。比如，J2EE 平台的两大主要竞争对手 BEA 和 IBM，也往往是某些 JSR 的共同发起者。比如曾经是一个“模式”的 SDO， WORKMANAGER，都由这两家共同发起成为了 JSR。前阵子，OASIS 的众多硬件软件提供厂家共同组织了一次 WS-Security 标准户操作性实验室，把业界所有的玩家汇集到一起，用各自的软件混合进行互操作性系统测试，也是竞争对手为了推动业界标准而全力合作的经典案例。

如果你认为 JCP/OASIS 这些业界联盟是大公司的俱乐部，那么开源运动并不比 JCP 更纯洁。开源运动，自由软件运动等等由来以久，但是最近几年才突然全面开花。这里面自然有开源软件运动不停贡献的因素，但更关键的是几个大厂商，尤其是IBM，为了制衡自己的竞争对手而采取的一个战略手段。比如，名义上是“开源”的ECLIPSE，实际上绝大多数贡献者坐在IBM的某个办公室里。AXIS 里也不乏IBM的雇员和前雇员。APACHE, GERONIMO, 都和IBM有某种程度上的渊源。。APACHE 的另外几个著名项目，比如著名的 XmlBeans, Beehive，则彻头彻尾是 BEA 的产物。至于 SPRING，最近和 IBM，BEA 都越来越亲热。甚至于，IBM ASPECTJ 的首席，干脆跳槽去了INTERFACE 21。

所以，如果你认为 JCP 是大公司的傀儡，而开源运动是JAVA的救星，呵呵，那你需要再仔细琢磨琢磨。

最后，关于“开源框架”：

首先关于“开源”：要讨论“开源”，就不能不讨论它背后的经济因素。

单纯作为一个软件开发模式的“开源”运动，在历史上曾经产生过极端高质量的软件产品，比如GNU和LINUX。但是脱离了作为商业运作模式的“开源”，“开源软件运动”一直只是狂热爱好者的俱乐部，没有进入商业开发的主流。

今年来的“开源”，和历史上的自由软件运动有两个重要区别：

1． 大厂家在背后的支持。这里面有众多因素，比如与微软抗衡的因素，J2EE 厂家互相之间竞争的因素。
2． 更深层次的，是软件业的整体衰落。软件业自.COM爆炸之后尚未产生重要性与WEB相当的所谓KILLER APP。J2EE, .NET更多地是软件业内部生产工具的重构。

现在的“开源”运动就是在这种背景下产生的。被“开源”的项目，虽然有业内的众多炒作，却不过是没有更好的产品创意情况下，退而求其次的作法。“开源”运动的最重要推动者IBM，本身已经确立了以服务为主要商业模式的战略，而软件产品收入本身的战略地位则大大下降。

其他的重要“开源”机构，比如INTERFACE 21和JBOSS，都是以服务、咨询为主要业务。这个模式的特征是，软件产品本身并没有多少竞争力（SPRING卖几块钱合适？JBOSS和WEBLOGIC比起来卖几块钱合适？），卖点在于服务和咨询，而软件是白送的。

作为软件开发者，从我的个人价值取向出发，我不认为这是一个可取的发展模式。这个基于咨询服务的模式或许更适合于印度，而不适合中国或者美国。如果软件业的未来是咨询，那么我宁愿改行做生意。

幸而，软件业还在发生不断的创新，真正意义上的创新，而不是“SPRING框架”什么的。我个人乐见的发展，包括salesforce.com这类“软件即是服务”的模式。当然，此“WEB服务”非彼“咨询服务”。

第二，关于“框架”：站在应用开发的角度看，应用开发（和使用）应该是简单的，轻便的。应用开发应该象VB，象DELPHI，象POWERBUILDER。如果在JAVA语言＋IDE之外，还需要更多的“框架”，“模式”，XML配置才能工作，那么这个语言需要改进，而不是采取“框架”和“模式”补丁。

这么说，并不是意味着我本人更喜欢写VB或者PHP。（事实上我更喜欢HASKELL）。我这个说法的含义，是指有志于中间件或者软件工具开发的开发人员，应该着眼于开发下一代更敏捷的应用开发语言，下一代更易用的应用开发平台环境，而不是邯郸学步，人云亦云地搞本来属于“补丁”范畴的“框架”。

从历史上看，“框架”从来没有长寿过。OWL，MFC，作为主流商业应用开发工具，它们的生命力都是那么昙花一现。EJB3即将到来，SPRING也快成为昨日黄花了。

事实上，SUN内部久已酝酿抛弃JAVA。不久前SUN的前CTO公开声明JAVA的生命力已经衰落。而JAVA 6 (代号MUSTANG) 已经开始大规模加入对脚本语言的支持。作为应用开发首选语言的JAVA地位如果皮之不存，“框架”又毛将焉附？

从技术讨论到技术标准再讨论到技术趋向，呵呵。以上纯属个人意见，如有雷同，那“英雄所见略同”。如有反对，明后年考RUBY证书的时候别忘了Kyle呕～～～

to Kyle_Yin ,
听君一席话胜读十年书！
浏览了一些你的贴子，感触最深的就是，看来您大应用，小应用都搞过！看问题比较全面。有空多来灌灌水：）

承让承让，折杀本人了。

小应用当然搞过，大家都是这么起步的吧。所谓做大应用，自然是做其中一部分或者几部分。不过本人有幸多接触了几个系统的几个子系统的几个方面，不是比别人见多识广，只是比别人跟头摔得多而且狠罢了。

框架成为Java编程主导，这是一个完全事实，你试图通过Java语言消失这个概念来否定框架，可惜，你不了解框架是什么定义，模式和框架是依赖语言而存在的吗？

<b>模式和框架是独立于语言存在的</b>，IBatis/Hibernate都有.NET下的实现啊。Java语言消失，怎么会有框架消失，还皮肤不皮肤呢，我看消失的是那些重型的工业厂商平台。

请大家讨论客观专业点，就自己了解的领域多谈谈，谢谢。

下面附Java 23种模式简介：
http://www.jdon.com/designpatterns/index.htm

另外关于一个超难问题需要解决，请真正专业人士来解决：
http://www.jdon.com/jive/thread.jsp?forum=91&thread=23857

我想他指的是那种融合了已知模式和框架的“应用开发语言”，不过到那时还会有更高层次的“框架”，“模式”。不过若是有的话，估计也是很遥远的事情，应该不会让我们没有饭吃的：）

至于标准，自古以来就有其优点和缺点，要想改变标准，违反标准，或者改变标准的制定者，谈何容易，他自古以来就是各种力量较量的一种产物。

这个主题的讨论很充分了。老板如果仔细看看我对框架的讨论就会意识到我对框架批评的立论基础并不是JAVA本身的生命力，而是当前的“框架”的性质。

框架的短命现象，非常常见。

STRUTS 高峰期的流行程度，远远超过SPRING，并且流行的周期也远远长于SPRING。可现在还有很多人用 STRUTS 么？呵呵。

明年还会有很多人用 HIBERNATE 么？JBOSS 自己已经在向 EJB3 PERSISTENCE API 过渡了。

明年还会有很多人用 SPRING 实现“依赖注射”么？看不出道理。

别吵了,吵什么吵,我还要睡觉呢!

Struts Spring Hibernate等都是框架产品，而不是框架或者说框架理念设计，这两者不能让初学者混淆。

只要是产品，有形的东西，就有生命周期，讨论产品的生命周期是没有意义的。

EJB本身也是一种框架，JBoss等是EJB框架产品，EJB不但是框架，而且还是上了标准的框架，这就延续了它的生命力了，因为标准可以随着技术发展修改，两代框架之间可能根本不需要一样。这是EJB坚挺的原因。

而一些开源框架产品则没有这么好待遇，他的框架产品代表的框架理念没有形成标准，所以，他的生命力就不能持续。

这也是本文提出的前提，象Struts/hibernate/Spring这些好框架产品因为被排除在标准之外，而被扼杀，但是我们用户一直在用它的。这种不公平的情况让我们不得不怀疑，标准是一件好事情吗？

现在，从过去一段时间来看，标准已经不是我们用户实际应用中的标准，而是代表工业厂商利益的标准，标准已经失去了它本身的意义。

当“标准”的东西不是我们大多数用户使用的，而且“标准”本身又扼杀和阻碍了技术的发展，这样的“标准”还要它个球？

Java领域就是这样令人痛苦。

No, No, No。

首先，“我们用户”不但在使用标准，并且是天天用，时时用，人人用。如果你用STRUTS, WEBWORK, SPRING MVC，那么你肯定在用 SERVLET 标准。少了这个标准，这些框架通通都是不可能的，这里很多人可能今天都在写 ASP.NET 了。不但如此，SPRING 基于 JAVA BEAN,XML, DOM 标准，SPRING 的插件基于 JDBC, JMS, EJB, RMI, ....这些通通标准。

如果你用JAVA,XML，那你就是在用标准。除非你改行写C#。

并且，这些框架的正面成分已经，或者正在形成标准，比如 JSF 来源于 MVC 但是又优于 STRUTS 的基于“页面”的MVC，EJB3 ANNOTATION 的依赖注射又优于SPRING XML的依赖注射。当然，绝对不可能形成 JSR 照抄 STRUTS、SPRING 的情况。不要说这些框架，即使 WEBLOGIC,WEBSPHERE，ORACLE 也不可能让自己的所有技术成为标准。

如果你担心被绑定在一个厂商身上，那么标准的意义正在于让你的 WEBSPHERE 应用能够在 GERONIMO 上跑。

并且，我想前面已经解释过了，JCP 的形式是透明而民主的。JSR 的形成不仅需要行业内的各方参与，也有“大众评价”的步骤。一些 JSR 标准历史上最引人注目的大举措，比如 EJB 3， JSR 133， 并不是由 IBM/BEA 主导的，而是来自业界和学术界的各方反馈。

老板的有些话，“标准已经不是我们用户实际应用中的标准，而是代表工业厂商利益的标准”， “当标准的东西不是我们大多数用户使用的，而且标准本身又扼杀和阻碍了技术的发展”，完全让人不知所云。

举例说明，哪条 JSR 扼杀谁发展什么技术了？

对这个话题的讨论，最初原因之一是之前我们关于 WORKMANAGER 的讨论。老板认为应该用 JMS，而不是什么“球”的 WORKMANAGER (JSR 237)。

老板在大骂“它个球的标准”之余忘了，你自己倡导的 JMS，不折不扣地，彻头彻尾地，完完全全地，百分之百地，也是“它个球的标准”。

我的意思关键就在于这一句：当标准的东西不是我们大多数用户使用的，而且标准本身又扼杀和阻碍了技术的发展!

如果你不明白，也就不明白J2EE这几年的发展史，信息不对称，就不想写了。如果没有其他人出来补充就算了，否则搞得我象和Yin个人老是唱对戏一样。

另外，不要介意这个讨论的来源，正因为有争议才拉出来讨论。