1.我们老祖宗说过，合久必分，分久必合。软件工程本身是希望从工程学的角度来控制工程的进度，混杂各种技术不是什么好现象，C++恐怕种类也不少，目前还有谁只写ansi C++的？看到漫天飞的makefile，各个版本的lib，不知名的头文件()，遍地的define，恐怕晕的不止我一个，多有耐心的人都要消耗时间来协调各个部分的程序(呜呜，我是低手，别臭我)，写了许久，还是某个平台的(确实有人可以写出移植方便的程序，但我辈低手尚我此种眼界和经验)。提到IA32真考倒了，java和jvm最好还是分开讲，信任一群公司的联盟可以提供更好的jvm，好象不只是我这么想。当然，java很多东西做不了，可以尝试通过JNI、CORBA、Socket等技术来调用万能的C++啊。十八班武器，那个没有自己长短处？不过现在做底层应用的，还是以C为主。不信，看看那些做通讯，电子的，哪个是在用C，而且将来也不一定会转到C++。2.java是什么？这个问题问的好，三年前，两年前，一年前，半年前，大家的理解都不同，本人第一次对这个问题有感觉有触发是在回答一份ibm调查问卷的时候。
java.sun.com/products下面那些东西，有谁看完了？我是看了几个，但起码知道跑java的设备目前已经存在了，虽然是手持设备或通讯类产品，而且不是只能跑java，但起码那也叫硬件。将硬件跟软件支持分开，这才是适应不断升级硬件、软件的最优结合方式，拘泥于技术的细节，忽略方向，这样子很被动的。3.被他的例子击中要害。没话讲，一是不熟悉，二是我也基本同意他的看法，除了3.1.3，小小细节就不必拖出来讲了。4.
4.1是个老话题了。的确，java效率通常要低于c++，但是它是挂在jvm上运行的，比通常的C++运行多了个壳，而且用循环来比较的话，恐怕这种举例更不公平，显然C++对于y = x * z优化跟java的处理有不同。如果一味强调编译器优化的某项特性，那java这边也可以做优化啊。运行态编译就那么不可行？别忘了，服务器上的程序没有哪个是运行一次就被重新执行的，而执行过一次，运行态编译就会体现它的优点，一个C++程序运行一次3秒，一个java程序运行一次6秒，这就说java慢？好，那么那个c++程序运行10000次就是30000秒，那个java还是这么简单乘法吗？请考虑统计数据采样的重要性。统计本身就是们学问，加减乘除都要有凭据的。对于两者效率差多少，个人意见：在不同的应用场合下来测试，这样可能客观点。
4.2预编译java谁说没有？SQLJ白出来那么久了。运算符重载在java就有一个"+"，如果C++中有反射的话，相信灵活性会有更大程度的提高。模板类都是C++的精华，我也非常喜欢，那是C++中的奇迹，ATL和STL活在一群热爱C++的程序员里面，但是其它语言又有谁支持了？类型约束，呵呵，如果程序员连类型都写错，那么在C++不需要改吗？多继承是个老话题，不过从com/dcom、corba这些技术，恐怕接口比多继承更受欢迎吧。毕竟超过二层的多继承在C++应用实例也不常见，主要原因是没必要，而且程序难调。AWT的确不是很受欢迎，4年前，人们都以为AWT就是java全部，结果多少人放弃java，但现在情况就完全不同了。java可以将程序压缩放在jar文件中，以减少文件尺寸和方便管理，不过pe的也有压缩加壳技术，但是终究不是系统级支持。
4.3扯多点东西，那位老大一定对信号量等同步技术非常重视，在java中实现非常简单明朗，C++也麻烦，那么关于资源如何释放对于程序员就只是个编程的习惯，相信在java中忘记关掉stream的人在C++也可能犯同样的错，而且结果也会相同。允许C++程序员在析构函数多写几行关闭，为什么一定认为java程序员会忘了呐？如果java是骗局，那么这是一场跨国多巨头联合超级大骗局。5.java发展时间不长，比c++是年青太多了，年青到基本框架到处都在搭建，jvm的版本也是很多，我现在使用的是1.2.2_005，对个人影响也许不大，但这个对公司的影响确实比较大，没有哪个公司愿意为jdk1.1.x和jdk1.2.x写两套软件，但这个就好象c++的库版本管理混乱一样，没有哪种技术一开始不需要伤筋动骨的改造，perl的下一版都在重写呐。6.
6.1好象软件工程要求你在写代码前先干点什么，这个应该不算java的问题。是采用如何的方式学习和应用语言开发的问题。在工程里面说明一遍，然后再在header里面写一清遍，恐怕算是浪费体力吧。javadoc强烈推荐大家使用，可以根据代码生成象jdk那种结构清晰的文档，写完程序，这种文档也可以作为补充。
6.2呵呵，又是多继承。实例举多了，不利于帮助了解事物的本质。
6.3析构，呵呵，析构中再调用其它的析构，好处可以自己定制析构，但是对于调试程序恐怕也会带来多一些麻烦，这个世界上的程序员还是要靠debug来吃饭的。析构到底有那么神奇，令仁兄接二连三提起？
6.4许多人都讨论过一个大对象好，还是一堆小对象好，那么本人的看法是如果一个大对象完成所有工作，那么就将问题局部化，调试范围集中在一个文件，但不利于多人开发，而且功能升级也不方便，重用的可能更小；如果多个小对象，可以分工明确，功能升级有可能减少代码的修改量，最大可能重用组件，对于项目管理的确是个挑战，看似简单的小对象之间的架构才是component比oo多出来的精髓，但使用不当会令工作事倍功半。这个问题对c++和java都成立，但是由于语言的风格不同，所以受重视的程度有不同，许多人在学习java的过程里面都会思索、比较这两种模式。
6.5移植的东西就很难讲。ibm和oracle都要在palm上搞数据库，ibm是改写的，oracle是重写的，那么哪个服务器软件不是一大堆for各个版本的不同操作系统。这些就是摆在眼前d的实际问题。不知不觉，64位又要大行其道了。
Fortran77和basic现在也有人用，甚至cobol用的人都不少，为什么？商业社会不允许随便放弃过去，推C++的时候面临的是同样问题，怎么就这么快忘了呐？
java的基本类型比较少，这个是事实，之间转换也不是非常灵活，但是c++中，类似整除和取余更是通过函数实现的(顺便提下，基本上c++中每一个内置函数都有功能相同名字、类型不同的，这些恐怕也不是什么好现象吧)。细节问题，不至于影响对java发展方向的评价。
全局变量这种东西可以放在一个类中包装啊，c++也是希望减少使用全局变量、宏编译，联合体出现的年代，String都不是数据类型，操纵起来也要处处小心。现在用联合体的场合一般是厂家提供的api需要，自己写程序用联合体的不多。用联合的语言就一定要支持指针，这是java所不愿走的路。
instanceof确实非常有用，因为java可以通过非常多的形式拿到类的实例，如果不知道是什么类或者实现了什么接口(别咬文嚼字，接口本身就是一种特殊的类)，可以让java的灵活程度大大加强。比起dll的动态加载，java的动态加载就是天生的，不需要那么多乱七八糟的规矩，而且可以通过jar来集中管理同属一类的java class。
反射是java的一大特色。
6.6呵呵，java可以骑着c/c++啊，jni是吃白饭的？通过jdbc可以调用数据库中的东西，jndi可以访问目录，jms可以访问消息队列，jts可以访问交易系统，javacard可以在sim卡上跑，corba可以调用任何支持corba的东西，socket可以调用任何支持ip的语言，rmi虽然只能用java，但是可以非常透明的得到实例，这是其它语言不具备的优势，适合网络分布计算。呵呵，这些只是非常普及的java技术之一小部分，它虽然不是什么崇高的理论，但是起码它能让许多计算机在一起工作，为应用服务，这才是我们最关心的问题。7.偏系统底层开发，我宁可用C，中间层开发倒是java，界面用些简单工具就算了。至于c++，恐怕只是当初在接触面向对象时看到的一个诱人的梦了。看了这篇贴子，有些感发，断断续续写了4个小时，才将思绪理的清楚一点，望各路高手指正。to w102272:
希望能帮我贴回你转贴的地方。 thank u.:)oicq: 1766598
mail: [email protected]
java.sun.com/products下面那些东西，有谁看完了？我是看了几个，但起码知道跑java的设备目前已经存在了，虽然是手持设备或通讯类产品，而且不是只能跑java，但起码那也叫硬件。将硬件跟软件支持分开，这才是适应不断升级硬件、软件的最优结合方式，拘泥于技术的细节，忽略方向，这样子很被动的。3.被他的例子击中要害。没话讲，一是不熟悉，二是我也基本同意他的看法，除了3.1.3，小小细节就不必拖出来讲了。4.
4.1是个老话题了。的确，java效率通常要低于c++，但是它是挂在jvm上运行的，比通常的C++运行多了个壳，而且用循环来比较的话，恐怕这种举例更不公平，显然C++对于y = x * z优化跟java的处理有不同。如果一味强调编译器优化的某项特性，那java这边也可以做优化啊。运行态编译就那么不可行？别忘了，服务器上的程序没有哪个是运行一次就被重新执行的，而执行过一次，运行态编译就会体现它的优点，一个C++程序运行一次3秒，一个java程序运行一次6秒，这就说java慢？好，那么那个c++程序运行10000次就是30000秒，那个java还是这么简单乘法吗？请考虑统计数据采样的重要性。统计本身就是们学问，加减乘除都要有凭据的。对于两者效率差多少，个人意见：在不同的应用场合下来测试，这样可能客观点。
4.2预编译java谁说没有？SQLJ白出来那么久了。运算符重载在java就有一个"+"，如果C++中有反射的话，相信灵活性会有更大程度的提高。模板类都是C++的精华，我也非常喜欢，那是C++中的奇迹，ATL和STL活在一群热爱C++的程序员里面，但是其它语言又有谁支持了？类型约束，呵呵，如果程序员连类型都写错，那么在C++不需要改吗？多继承是个老话题，不过从com/dcom、corba这些技术，恐怕接口比多继承更受欢迎吧。毕竟超过二层的多继承在C++应用实例也不常见，主要原因是没必要，而且程序难调。AWT的确不是很受欢迎，4年前，人们都以为AWT就是java全部，结果多少人放弃java，但现在情况就完全不同了。java可以将程序压缩放在jar文件中，以减少文件尺寸和方便管理，不过pe的也有压缩加壳技术，但是终究不是系统级支持。
4.3扯多点东西，那位老大一定对信号量等同步技术非常重视，在java中实现非常简单明朗，C++也麻烦，那么关于资源如何释放对于程序员就只是个编程的习惯，相信在java中忘记关掉stream的人在C++也可能犯同样的错，而且结果也会相同。允许C++程序员在析构函数多写几行关闭，为什么一定认为java程序员会忘了呐？如果java是骗局，那么这是一场跨国多巨头联合超级大骗局。5.java发展时间不长，比c++是年青太多了，年青到基本框架到处都在搭建，jvm的版本也是很多，我现在使用的是1.2.2_005，对个人影响也许不大，但这个对公司的影响确实比较大，没有哪个公司愿意为jdk1.1.x和jdk1.2.x写两套软件，但这个就好象c++的库版本管理混乱一样，没有哪种技术一开始不需要伤筋动骨的改造，perl的下一版都在重写呐。6.
6.1好象软件工程要求你在写代码前先干点什么，这个应该不算java的问题。是采用如何的方式学习和应用语言开发的问题。在工程里面说明一遍，然后再在header里面写一清遍，恐怕算是浪费体力吧。javadoc强烈推荐大家使用，可以根据代码生成象jdk那种结构清晰的文档，写完程序，这种文档也可以作为补充。
6.2呵呵，又是多继承。实例举多了，不利于帮助了解事物的本质。
6.3析构，呵呵，析构中再调用其它的析构，好处可以自己定制析构，但是对于调试程序恐怕也会带来多一些麻烦，这个世界上的程序员还是要靠debug来吃饭的。析构到底有那么神奇，令仁兄接二连三提起？
6.4许多人都讨论过一个大对象好，还是一堆小对象好，那么本人的看法是如果一个大对象完成所有工作，那么就将问题局部化，调试范围集中在一个文件，但不利于多人开发，而且功能升级也不方便，重用的可能更小；如果多个小对象，可以分工明确，功能升级有可能减少代码的修改量，最大可能重用组件，对于项目管理的确是个挑战，看似简单的小对象之间的架构才是component比oo多出来的精髓，但使用不当会令工作事倍功半。这个问题对c++和java都成立，但是由于语言的风格不同，所以受重视的程度有不同，许多人在学习java的过程里面都会思索、比较这两种模式。
6.5移植的东西就很难讲。ibm和oracle都要在palm上搞数据库，ibm是改写的，oracle是重写的，那么哪个服务器软件不是一大堆for各个版本的不同操作系统。这些就是摆在眼前d的实际问题。不知不觉，64位又要大行其道了。
Fortran77和basic现在也有人用，甚至cobol用的人都不少，为什么？商业社会不允许随便放弃过去，推C++的时候面临的是同样问题，怎么就这么快忘了呐？
java的基本类型比较少，这个是事实，之间转换也不是非常灵活，但是c++中，类似整除和取余更是通过函数实现的(顺便提下，基本上c++中每一个内置函数都有功能相同名字、类型不同的，这些恐怕也不是什么好现象吧)。细节问题，不至于影响对java发展方向的评价。
全局变量这种东西可以放在一个类中包装啊，c++也是希望减少使用全局变量、宏编译，联合体出现的年代，String都不是数据类型，操纵起来也要处处小心。现在用联合体的场合一般是厂家提供的api需要，自己写程序用联合体的不多。用联合的语言就一定要支持指针，这是java所不愿走的路。
instanceof确实非常有用，因为java可以通过非常多的形式拿到类的实例，如果不知道是什么类或者实现了什么接口(别咬文嚼字，接口本身就是一种特殊的类)，可以让java的灵活程度大大加强。比起dll的动态加载，java的动态加载就是天生的，不需要那么多乱七八糟的规矩，而且可以通过jar来集中管理同属一类的java class。
反射是java的一大特色。
6.6呵呵，java可以骑着c/c++啊，jni是吃白饭的？通过jdbc可以调用数据库中的东西，jndi可以访问目录，jms可以访问消息队列，jts可以访问交易系统，javacard可以在sim卡上跑，corba可以调用任何支持corba的东西，socket可以调用任何支持ip的语言，rmi虽然只能用java，但是可以非常透明的得到实例，这是其它语言不具备的优势，适合网络分布计算。呵呵，这些只是非常普及的java技术之一小部分，它虽然不是什么崇高的理论，但是起码它能让许多计算机在一起工作，为应用服务，这才是我们最关心的问题。7.偏系统底层开发，我宁可用C，中间层开发倒是java，界面用些简单工具就算了。至于c++，恐怕只是当初在接触面向对象时看到的一个诱人的梦了。看了这篇贴子，有些感发，断断续续写了4个小时，才将思绪理的清楚一点，望各路高手指正。to w102272:
希望能帮我贴回你转贴的地方。 thank u.:)oicq: 1766598
mail: [email protected]
ASM功能最强，执行效率最高，难道你还用它作你的管理系统。
你可以想象，以后要在洗衣机、电视机、PC等不同的平台上运行同一套程序，C++代价是多大？
你可以看到Oracle,IBM的大型软件现在都在转向Java.还有IMS的ERP号称都是Pure Java.
IBM、Oracle的软件工程师从以往的90％的使用C++到现在的90％的使用Java,可以看到Java的
的活力。
就是Microsoft也不敢不支持Java.
所谓走自己的路，任别人去说吧，我们选择了Java当然是看到了他的美好前途。
我本来学JAVA的兴趣很高的，经你这么一说、、、、、哎，纯粹是打击我！！！！
嘿嘿，还是hicharlie这住老兄给了我一点信心，我真怀疑你是不是给微软打广告的！
OK，只因我还没入门，不能作出高深的评论了！！！！希望以后不要出现类似去打击别人的
东西！！
我很喜欢用微软的东西。一家公司作大了，总会有人看着不顺眼的。
在开发网络应用方面，目前jsp等技术基本上已经超过了ASP。jdbc2.0挺好的，有些方面是比不上ADO，很多的数据库支持的不够好，但不可否认JDBC2.0是很好的东西。java相对而言，简单易用，很好学，精通一门Java语言，就可以做简单的做很多事情，而在Windows平台你需要精通很多种语言，才能比较简单地做很多事情。不知微软推出的ASP＋会怎么样？
各有各的好处，java和C++的竞争并不是很大。
one may know the influence of Java and its design idea.Java extremely decrease the complexity of a project development, as long as the developers are well-trained. It's really a miracle, if we put the performance aside. And there's always trade-off between performance and the efficiency of a system.
不过cxgtommy老兄驳斥的尚不够力度，我就其无法驳斥的第3点驳斥一下
3.1.1
首先，w102272怪数据类型没有boolean，其实在大多数编绎器里boolean(bool)都是用int来代替的不信可以看看VC；至于无符号数，因为Java要考虑跨不同处理器所以才取消的。如果非要就此置疑那C呢？returnAddress具体多少应取决于具体处理器的字长，这并没有什么问题啊？double和long是在IA32下存在原子问题,所以sun建议使用时应采用synchronized括起来，其实对于其它的数据类型操作时也应这样，毕竟有的处理器上可能是<32位的
3.1.2
w102272对汇编学的不错，不过Java采用的指令个个有用啊!你哪道不知道为什么Intel推出64位新芯片，就是因为它自己都认为以前的设计太复杂了。另外，I386指令并不能显示并行执行啊？你是不是什么地方搞错了？
新的64位芯片对于C/C++的并行优化，但Java可以使用JIT本地编绎，也可以先将可执行体一起翻译过来，然后再执行不就行了，这样的JVM不难实现啊？
3.1.3
对于返回是异常，这其它挺好的。异常是面向对象设计的方向，连C++都这样,C++也需要下层封装吗，哪道你喜欢使用GetLastError()从Socket接受错误码？使用异常一并捕获不更好吗？或者你喜欢接受错误时一定要知道它是由中断发出的还是由陷阱发出的？
3.1.4
Java不是用来编写操作系统或者设备驱动程序的，进入系统态干什么？能不能举例说明一下如何实现恶意操作
在I386以上平台，内存是存在保护的，错误的指令和非法的IO访问都是不被允许的
3.1.5我也来个小结
通过适当使用JIT，Java是可以实现C++的速度的，但确更可靠；或者先编后执行也可以。但这并不是将Java源码删除，怎么会有可移植性问题呢？
Java还是很有用的，Jini就很有前途
最近Linux迅速流行使得使用平台无关的开发语言就很重要--Java真的很有用
请问，java的代价是多大？？我不否认java的优越性，我也学习它，但是同时我也学习vc
java是救世主的看法不对，语言而已，各有所用，各尽其能，如是而已。linux火到现在，也没能普遍地走入pc中，还需要很长时间--现在的linux还有没有年头那么火？？
一切是做出来的，过分的炒作很容易让人忽略掉技术的东西
跨平台这个特性对很多领域是极为宝贵的，特别是开发客户端。
我喜欢Java ，做了很久的C＋＋ 之后，觉得写稳定的应用一下变得简单了，
因为这样就能使象我这样的菜鸟，能够对各种编程语言和方法有一个清醒的认识。
我了解JAVA语言不久，我希望在我决定将JAVA作为我的吃饭的工具之前，能比较透彻的理解它。
相信有不少人还在徘徊。
谢谢！
我知道贴这个帖子本身，就会有人赞同，有人丢砖头。（我是转贴，所以砖头会少些，^_^）
其实对JAVA，我自己并不熟悉，贴上来也是为了看看别人的意见。帖子结束了，我也发表一下自己的看法（感性认识），看是不是能够从另外一个角度来看JAVA：1、发展迅速，体系优秀
java从出现到现在，发展迅速，JDK是开始的东西，J2EE是近来的东西。
作为一种面向对象的分布式计算体系，就体系上来看，确实很优秀，
解决了过去集中计算和C/S体系一些不能解决的问题，这个问题不细说，楼上的人更明白。2、JAVA进入成熟应用尚有时日
JAVA眼前的问题多多，尚无法进入中小企业应用，也不是一种成熟的应用技术
具体的限制包括这么几个：
执行速度慢，对机器要求高，开发效率低（部分因为版本剧烈变化的不兼容），
跨平台的承诺并未在事实上完全做到（标准的变化，和公司的竞争性发展结果）
JAVA体系尚在不断发展中，远期的统一标准尚未建立，
近期的产品不成熟（比如JDBC的中文问题）等等 因此，目前用JAVA建立成熟的企业应用，尚有困难。JAVA目前的现状，不符合企业应用
要求的稳定性（而不一定是技术先进性），快速低成本开发（开发成本、质量、和效率），
以及标准化、应用平台独立于实现技术，以及远期扩展性要求
（注意：后面的这点不是说JAVA的跨平台特性，而是JAVA标准和版本不断变化导致的，
例如：JSP,JDBC这些基本的东西都在不断变化版本，产品的向下兼容性差，
这无疑会大大增加开发商的开发、维护成本；加大开发风险，
并影响目前提交给客户满意产品的能力
）等等。
而从这个角度看，很多企业发展JAVA，
主要是出于采用了SUN,IBM这些公司的硬件和操作系统平台，
或者是出于远期对产品策略的考虑，比如：希望利用跨平台建立异体系统一应用的目标
或者是出于技术人员对发展中的JAVA体系把握的目标 等等3。JAVA体系应用，有的成功，有的失败
JAVA被一致接受后，各大厂商争相对JAVA体系投资开发，以便在竞争中占据主导地位。
但另一个方面， 对JAVA缺乏标准的开发性竞争，导致JAVA跨平台，被一致接受的扩展（标准化）
大打折扣，并在某种程度上反而阻碍了JAVA的发展（关于这一点，我们看看UNIX，就知道了） JDBC,JINI,JNDI等等,看起来完全象包裹在JAVA一致语法下的不同东西。
JSP，JDK，不同的版本变化剧烈。
JAVA APPLET受低带宽传输，JVM兼容性，执行效率低等影响，一直难以运用。后来，反而受到类似
Flash这类美工类产品在IE前端的竞争（这一点，请大家看Flash 5的新特性）。 JAVA以Applet 和JVM引起业界的注视，现在比较成功的反而是 JSP 和 ServerLet 。
4。市场竞争措施，导致JAVA前途受影响。 大家要承认的是，技术先进性往往不代表市场成功。也不一定能够成为真正的事实标准。
就市场竞争上看，微软虽然没有阻止JAVA出现，但是通过IE，VJ＋＋，和WINDOW平台，以及
上面捆绑的大量最终用户和开发商，成功地阻止了JAVA成为事实分布式计算体系（包括操作系统）
的一切计算基础的目标，使JAVA现在还仅仅不过是一种语言和发展中的软件产品。 而作为语言，JAVA的优秀性和先进性大打折扣。
就实际效果来说（不讨论技术先进），方便不如VB，低层开发不如VC和DELPHI，作数据库应用不如PB。
虽然JAVA远景美好，但是有多少企业，尤其是中小企业经得起重建计算平台的折腾呢？
它们没钱配置SUN和IBM的高档机器，也不愿意花钱将产品从过去的平台全面改到JAVA体系上来。
至于做WEB应用，ASP+SQLSERVER的模式简单方便，LINUX+PHP的模式非常省钱，
用JAVA平台，最少要配置ORACLE DBA，大批高薪的JAVA程序员，还有一些企业为解决JAVA兼容问题，
本来就不应存在的“JAVA配置工程师”？！ 等等，非有钱者不能为。 这种局面持续下去，
.NET，C#（分别对应体系和语言）吸收了JAVA的概念和长处后，也开始冒出头来。
SUN作J2EE的工程师，半数以上被MS高薪挖走。
APPLET受到FLASH技术的挑战。
看起来，真是有点为JAVA前途担心（尽管可能多余）。综合上述看法，可以有几个结论：
1: JAVA最可能成功的地方，可能还是在原来JAVA提出的消费类电子市场（因为JAVA特别适合这个领域），
再就是大公司的产品体系的支持技术（比如：IBM WEB服务器,ORACLE数据库等）因为有大公司支持。
2：应用系统层面上，JAVA尚不成熟，为了回避风险，目前对采用JAVA作工程要慎重。作学习和研发
应用系统平台还是可以的。（因为产品周期比较长，可以等待应用稳定，等待统一标准的出现）
3：随着时间的推移，JAVA产品和技术还会受到更多的挑战和竞争。最可预期的结果是，JAVA
既不会做到它的目标“JAVA是EVERYTHING”，也不会完全消亡。所以作为软件开发者，不要把所有
精力都投入JAVA里头，最好同时也看看ASP+,COM+,.NET这些东西。尤其是现在拿着比其他程序员高薪的
JAVA程序员。
3：作为面向对象的分布式计算体系，非常优秀；应该将JAVA体系和目前产品的很多概念加以吸收，
这些概念对应用开发层面也很有意义。（毕竟中国的大批软件公司还是做应用产品和平台的）
JAVA，.NET或者其它方式都是实现应用分布的途径，通过分布式计算实现应用分布才是真正的目标。
就这个意义来说，C/S模式在INET模式下的改造（比如：OICQ或者联众游戏大厅）也是很成熟的手段，
JAVA将是走向应用分布计算的重要途径，但是绝非唯一途径。