java走向灭亡

很多年以前，有人预言面向构件（组件）的编程将大行其道，80%以上的软件将用面向构件的思想编写，银弹马上就要出现了……新兴的组件市场将让软件公司变成装配工厂，程序员沦落为蓝领，工资会降低……|
|
|
很多年过去了，这个市场从来没有出现过，偶们还是整天加班，唯一说中的就是最后一点……

头一次听有人认为“配置编程”是好东西。

实际上，很快就会被淘汰的，正是“配置编程”，包括它的代表 SPRING。基于XML的配置编程，本来是一个不得已而为止的办法，而不是什么高超优雅的设计。在ANNOTATION出现以前，人们曾经用XDOCLET来减少配置项目的数量。EJB3 直接在 JAVA 代码里以 ANNOTATION 的方式实现依赖注射，包括资源依赖和组件依赖。与配置编程相比，这不但大大提高了工作效率，更遵循单一代码原则，减少维护对象数目。

“配置编程”有一些致命的问题：

首先，一个完整的功能必须由多项文件共同支撑。增加了BUG几率。

更重要和更本质的问题，是“配置编程”破坏了OO的封装原则，把属于对象内部实现细节的依赖关系暴露在配置文件里。由于配置文件是在生产环境下可以更改的，这就从根本上破坏了组件设计者对组件部署环境的控制。维护和支持过套装软件产品的技术人员大概会有体会：把产品完整性寄托于明文的配置文件上，等于自讨苦吃。

关于 SPRING 和配置编程的前景，JBOSS的架构师/写手/传教士，ENTERPRISE J2ME的作者，MICHAEL YUAN最近曾经著文评论过。由于“配置编程”而喜欢上SPRING的各位同仁，该是看看EJB3的时候了。

SPRING 的几个大卖点，依赖注射，声明式事务控制，EJB3 都以规范的形式加以支持。并且，由于充分利用 JAVA5 语言层面的特性（主要是ANNOTATION），EJB3 对这些功能支持更加优雅方便。SPRING的MVC层，对于有JSF开发工具的程序员来讲，更没有什么吸引力。

SPRING 比 EJB3 强出的唯一一个方面是 AOP。EJB3 支持 INTERCEPTOR，但是仅此而已。ROD JOHNSON 和 IBM 明显已经意识到了这一点。这就解释了 ASPECTJ 的头头为什么最近从IBM投奔了INTERFACE21。

说 JAVA 要被淘汰，并不是说 JAVA 就要完全消失了，而是说编程语言将进一步细化，单独出业务应用语言和系统框架语言。这就类似当年从汇编里分离出来了C, 有进一步分离出 C++, 然后再次分离出JAVA/C一样。

说JAVA会完全消失，就好像说C/C++/数据库会灭亡一样。即使在今天，LINUX KERNEL还是要用汇编＋C写，不是吗？

编程语言将再次细化分工的原因，和以前的几次一样，是计算机工业生产力发展的必然规律。 记得当年的C/C++程序员都对JAVA有强烈的排斥和轻蔑心理。很多人认为一个不能访问内存地址和IO端口的语言充其量只能叫做玩具。 但是事实是，JAVA 所试图解决的问题，并不是硬件系统操作和资源管理，而是抽象的OO逻辑表达。站在系统和资源层面看待JAVA，当然不会相信有一天JAVA会取代C++成为用户群最大的语言。

今天的JAVA面临当年C/C++类似的问题：同一个语言被赋予了多种角色。 对于占程序员绝大多数的 应用开发者 而言，JAVA 是一种业务逻辑描述语言。应用开发者所关心的问题，是如何在最小的代价下最准确忠实地完成业务功能需求。站在这个层面上，JAVA提供了过多的灵活性: 比如 Thread/ThreadLocal 出现在JDK里，在 J2EE规范 却禁止应用程序使用这些API。又比如 SWING，或者现在流行的 AJAX & JSF|STRUTS|WEBWORKS，写商业应用图形界面并不比VB/POWERBUILDER/DELPHI简单。虽然J2EE规范努力试图弥补 JAVA 功能 和 商业应用需求之间的差距，这个过程却不是一帆风顺的。现在已经出现了几个JAVA技术栈的替代品，不如 RUBY ON RAILS，PHP。

作为 JAVA 程序员，在你嘲笑这些东西简陋之前，记住当年C/C++的前车之鉴。

另一方面，而对于WEBLOGIC, JBOSS, WEBSPHERE, GERONIMO, APUSIC而言，JAVA被用来实现所谓“容器”，“商业操作系统”。在这个层面上，JAVA 的语言设计很多地方显得捉襟见肘。 比如，AOP 是一个系统编程的极其自然的设计方案。在系统安全，授权，认证，事务，日志等等方面都可以作为非常优雅的架构选择。事实上，APUSIC，WEBLOGIC, JBOSS也的确用不同的方式各自实现了自己的AOP，IBM更是ASPECTJ的大力支持者。 然而，SUN 出于保持 JAVA 语言简单特性的考虑，坚持不在 JAVA 语言中加入 AOP 特征。

这种情况不会持续下去的。

历史经验表明，“模式”“框架”只是过渡状态。短短几年时间中，大多数“J2EE 核心模式”已经结晶成为几个“框架”，或者J2EE技术规范。然而，“框架”并不是这个过程的终点。正如同 win32 SDK -> MFC/OWL -> VB/DELPHI/PB 一样，EJB3/SPRING 以后必然会出现在更高层面上进行抽象的语言。

所以，JAVA最终必然将在应用开发者和系统开发者中选择其一。目前看来最可能的情况是将产生另一个应用开发语言。

Kyle_Yin说的很有道理，现阶段的“配置编程”不得已而为止的办法，这样做个人感觉也十分的繁琐。我想等这些配置再有一种工具或者语言或叫做组件描述语言，或者应用开发语言来管理的时候，java也将会退到c语言的位置了。
发此贴的目的在于，抛块砖头：）

TSS最新的一篇文章: Rubby没有这么快替代Java，是华人袁先生写的，袁的网页以前关注过，非常不错。

http://www.theserverside.com/news/thread.tss?thread_id=37540

MICHAEL YUAN的观点很有道理，但是也有一些问题。

他说ROR不会取代JAVA的最大原因是因为在 WEB 应用方面JAVA已经足够好了，没有足够强烈的经济动机能让人们用ROR取代JAVA。

那么VB呢？

当年的C++ & MFC|OWL也是相当好的 WINDOWS 应用解决方案，但是最终 VB|Delphi|PowerBuilder 成了中小商业应用和游戏前台的首选语言。当然，4GL语言最擅长的是小型项目，而不是大型系统的后端。这和ROR/JAVA的对比非常相似。在开发小应用方面，ROR远比JAVA来得方便，但没有人说要用RUBY写个应用容器。

Yuan同学关于为什么科学计算程序广泛用 FORTRAN 的论述更是误入歧途。作矩阵运算 FORTRAN 当然比 C 方便得多，不必分配和管理内存，数组是内建数据类型而不是一个指针的等价品，可以动态改变数组大小，等等。FORTRAN本来就是设计用来干这个的，FORTRAN的编译器也针对矩阵运算做了高度优化。而 C 的长处在于系统资源管理，和 FORTRAN 根本就是一个斧头，一个螺丝刀的关系，谈不上谁比谁先进，谁替代谁的关系。

Yuan同学毕竟是学天文出身。在计算机语言方面有些门外汉。

> TSS最新的一篇文章:
> Rubby没有这么快替代Java，是华人袁先生写的，袁的网页以?
> 关注过，非常不错。
>
> http://www.theserverside.com/news/thread.ts
> ?thread_id=37540

>Yuan同学毕竟是学天文出身。在计算机语言方面有些门外汉
Yuan最早我关注的是他的J2ME，他主要做这方面的工作，现在到JBoss公司工作了，从事Java服务器方面开发研究，它对Java在嵌入式系统有相当研究，出了几本书都是关于这方面的，所以他对Java的强大的跨平台、anywhere特性有较深的了解。

看看他的别墅和车子很让人羡慕，25万美金在上海只能买一个市区公寓，你说上海泡沫大不大？转移话题了，sorry，主要是对比两个国家的程序员生活啊。

呵呵，我也差点买他那本ENTERPRISE J2ME。不过毕竟和工作不是那么直接相关，而且当时BOOKPOOL没货，也就作罢了。

从Yuan同志到JBOSS以来的文章产量看，他的工作可能不是开发性质，更接近 咨询/传道师的角色。我无意贬低袁同学，也基本赞成他的大观点（语言的驱动器是经济和应用因素，而不是语言本身），不过他关于FORTRAN的评论的确相当业余。

你怎么知道他那个房子25万美金？看来德州房子真的好便宜。

> TSS最新的一篇文章:
> Rubby没有这么快替代Java，是华人袁先生写的

You guys should read Obie Fernandez's blog item about "Unwitting Ruby Evangelist" (http://jroller.com/page/obie?entry=recovering_data_integrity_addicts_and). Everybody knows that Ruby/RoR will not replace Java/J2EE. In fact there wasn't, and will not be anything replace another. Did Java replace C++? Not at all. They are for different business. On the other hand, Michael Yuan said that "RoR is advanced compared with JavaEE", that's really interesting.

BTW, Michael is known as a J2ME expert. Yet another interesting fact, right?

话可别说太早了。 呵呵。 JAVA 有没有代替 C++ 大家有目共睹。 ORACLE, SAP, PEOPLESOFT, JDEDWARDS 什么的，这些ERP应用算大型系统了吧？7～8年前这些东西基本上是纯粹的 C/C++，但是现在 C/C++ 方面的开发已经基本完全处于维护状态。新功能开发说九成是在JAVA上做的恐怕不夸张。

说 JAVA 代替了 C/C++， 并不是说所有的 C/C++ 程序都用 JAVA 重写，而是说在应用领域，绝大多数新项目是基于 JAVA 的，正如10年绝大多数新应用项目开发是基于 C/C++ 的。

说 JAVA 将被代替，也不是说要用 RUBY 写个 R-BOSS 什么的应用容器，而是指（很有可能）某种脚本语言将代替 JAVA 成为 WEB 应用前端的首选开发语言，而 JAVA 继续作为应用服务器和组件实现语言。请考虑以下三点：

1。MUSTANG 已经在 JVM 和 语言规范两个层面 加入脚本语言支持。这已经在为 JAVA 的专用化，和新语言的诞生做前期准备。
2。脚本语言前端 ＋ JAVA后端的架构设计已经得到了一定程度的应用。开源的自不待言，即使 WEBLOGIC 9，也以 JYTHON 作为配置和管理编程语言。
3。历史上，4GL 脚本前端 ＋ 3GL 组件后端 的体系不是第一次出现。 VB/VC++就是这种体系的典型的典范。10年前微软已经提出所谓DNA架构，其要点之一就是 4GL 的脚本语言VB作为前端业务实现和界面描述语言，而VC++作为服务和组件实现语言。
4。10年前，当商业应用程序员和操作系统程序员都在讨论内存管理的时候，C/C++ 的局限就很明显了。 今天，当容器程序员，框架程序员和应用程序员都在讨论“模式”的时候，JAVA 的大限就快到了。没什么新鲜的，分工的不断细化，是工业社会发展的客观规律。

> 10年前，当商业应用程序员和操作系统程序员都在讨论内存管理的时候，
> C/C++ 的局限就很明显了。
> 今天，当容器程序员，框架程序员和应用程序员都在讨论“模式”的时候，>JAVA 的大限就快到了。

呵呵，忧患意识很重要阿

>>但是现在 C/C++ 方面的开发已经基本完全处于维护状态。新功能开发说九成是在JAVA上做的恐怕不夸张。

Er...the best paid positions nowadays are C++ programmers, such as in telecom projects. You are right, most are maintenance, stable and well paid. So, IMHO, the value of Java programmers will be recognised only after "Java dead".

即使在JAVA程序员里，写容器的和写STRUTS、SPRING应用的也绝对不是一个报酬等级。

不少ERP实施顾问的报酬能到每小时一百美金以上，最近一些64位移植顾问听说也开到这个价位，有些银行里还养着一批薪水极高的COBOL程序员，但如果说 ERP实施，64位汇编 和COBOL 比 C/C++/JAVA 更热门恐怕谁也不同意。这些情况下他们的的卖点是领域知识，语言本身只占价值的一小部分。

换个角度想，1996年，一个对OO很有心得的程序员，如果当年看准方向向JAVA方向发展，现在可能已经有了一个令人羡慕的CAREER，不仅仅是WELL PAID那么简单。如果十年来一直在做C++，可能也就还是在TELECOM做个WELL PAID程序员不是(除非你在CISCO并有大笔OPTION)？事实上，早期的那批JAVA弄潮儿，很多就是从C/C++/LISP转过来的。BEA早年的几个顶梁柱就是从微软IDE跳出来的。十年之间这些人很多已经功成身退了。

在IT混，“稳定”不是很多人追求的目标。