回复关系：
作者 内容
 liujunsong  论Java的可移植性---不看会后悔的。。。
论Java的可移植性

Java的一大特点是其可移植性，也就是跨平台性，一处编写，到处运行。(Write once,run anywhere）。问题是，在实际的系统中，究竟有多少系统是需要这个特点的呢？
可移植性的获得，是以编程灵活性的丧失和性能的损失作为代价的。为什么这么说呢？要保证可移植性，Java编写的程序必须通过虚拟机和操作系统进行交互，再和硬件进行交互来进行，这样整个系统的性能实际上取决于这样几个方面：
1。操作系统对硬件的支持程度
2。虚拟机对操作系统的支持程度
3。Java程序对虚拟机的支持程度
4。上述三者相互之间的配合程度

而最重要的是第四者，也就是三种调用关系之间的配合程度，可是遗憾的是，操作系统在设计时，不会考虑到以后会有虚拟机在上面运行，所以第二种关系的协调实际上是矛盾的。作为虚拟机来讲，它需要获得对操作系统资源的最大可能的控制，而作为操作系统来讲，出于安全等方面的考虑，它必须限制虚拟机对于自己资源的控制。所以任何程序，当它运行在操作系统上时，它都不可能象操作系统一样获得对于硬件的控制权，而且操作系统一定会设法来限制它对于资源的使用，这就是虚拟机和操作系统之间必然存在的矛盾关系。

Java语言的设计，是站在虚拟机上来考虑问题的，所以它的设计风格，从操作系统的角度来看，是很难接受的。具体的表现，就是Java语言无节制地使用系统的资源，而系统的资源对于操作系统来说，是至关重要的。这些资源，主要是指对于内存的使用。当每一段程序都盲目的使用系统的资源时，系统的资源就会枯竭，操作系统最后无法完成资源的调配，系统就崩溃了。如果操作系统本身写的比较好，那么这种情况会少一些，而如果操作系统本身就不太稳定，那么这种情况就非常常见了。

在这种情况下，虚拟机作为Java程序和操作系统之间的中间人，需要调整和协调两者之间的关系，使系统处于一个稳定的状态，可是Java程序究竟写的如何，是由具体的程序员来决定的，所以虚拟机在一个假设的基础上进行协调和调和。

所以要有可移植性，就必须有虚拟机；有了虚拟机，就必须协调程序和操作系统之间的关系；要协调这两者之间的关系，就必须限制编程的灵活性；限制了编程的灵活性，就必然降低了系统的性能。这就是一个逻辑上的怪圈。从可移植性出发，得到了编程灵活性的丧失和系统性能的降低。

所以在使用Java时，编程越死板，系统性能反而越好，这就是一个非常奇特，又非常实际的问题。

可是编程太死板了，又难以构建出一个庞大的系统来，那么怎么办呢？于是就强调分工，强调层次，最后搞出一个J2EE的东西来，如同《封神演义》中的姜太公，各种技术一一到位，这下子天下太平，似乎可以毕其功于一役，把所有问题一下子全部解决。所以J2EE非常复杂，复杂得几乎让人望而却步。

所以强调在J2EE的框架下进行开发，这样子编程就非常死板，死板到了极点，就是第一行写什么，第二行写什么都定了下来。大家可以看看那些例子，那个不是如此呢？？？

但是这并不是真正解决问题的方法，因为这样做只是在破洞上打了一个又一个补丁，并不是从根本上解决问题的方法。为什么不能从根本上解决问题呢？根本的原因是在于对于自己提出的技术的盲目维护和盲目信仰，宁愿在上面打上漂亮的补丁，也不愿从新开始进行设计。

Sun与Microsoft之间的争夺，实际上是虚拟机和操作系统之间的矛盾的表现，这种矛盾，争夺的是对于硬件的控制权，争夺的是一个对于市场的垄断地位，从根本上讲，是经济利益的争夺。而Java语言，就成为了这种争夺的牺牲品。从技术上来讲，Java语言被过分地抬高了，这种抬高掩盖了Java本身的矛盾和不足，而这种不足在大型系统开发时会以其他形式表现出来，就是系统的性能不足和系统崩溃。

各种实现J2EE标准的厂商和产品，其实也是相应地做一些妥协而已，这些妥协，都只能在现阶段暂时解决这些问题，从长远来看，它们将带来越来越多的矛盾和问题，最终将导致依赖于此的现存计算机系统的完全崩溃，就如同互联网浪潮泡沫的崩溃一样。

结论：Java提供的可移植性，是一个美丽的谎言，整个计算机行业将为此付出惨重的代价。
 02/06/05 10:31 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 shaojl  回复: 论Java的可移植性---不看会后悔的。。。
你所说的确实很有道理，j2ee是存在低效、系统易崩溃等问题，但是在一个复杂的环境中，比如SUN、HP、NT等操作系统在一块时，确实提供了很大的方便。
 02/06/05 10:58 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 论Java的可移植性---不看会后悔的。。。
做一件事情嘛，贪图一时的方便，往往会带来以后无穷无尽的痛苦。
世界上的事情那一件不是如此呢？
 02/06/05 11:03 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  赫赫，老兄不能只站在WINDOWS程序角度说问题
实际在UNIX世界中，产品的可移植性和跨平台能力还是比较重要的。因为不同的UNIX太多了。
 02/06/05 11:28 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  如果没有程序，就没有这么多问题了
这也是我们为程序必须付出的代价。
 02/06/05 11:32 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 shaojl  回复: 论Java的可移植性---不看会后悔的。。。
事实上，各种技术的发展成熟都是因为人们为了更方便
 02/06/05 11:32 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 如果没有程序，就没有这么多问题了
如果你认为这些问题是不可避免的，
那么就会失去寻找答案的勇气。
那么就永远也找不到答案。
这种态度是祥林嫂的态度
 02/06/05 11:33 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  按照老兄的逻辑，OS也一样限制了人们的自由
只有硬件，甚至硬件也不能，只有“无”，才能给人最大的自由。砸破一切束缚我们自由的技术牢笼，换取一个新世界。
 02/06/05 11:37 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  建议你少看些辩证法哲学，多看些技术哲学，形而上的理论，复杂性方面的理论，计算理论，高等代数等方面的书籍。这样对你更深刻地理解计算机有帮助。
 02/06/05 11:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilingleo  回复: 论Java的可移植性---不看会后悔的。。。
我觉得现在看来java的优势并不完全在于可移植性，还有其他，比如完全的OO，良好的安全机制，入手的容易度等等。

再说，我们国内绝大部分系统都是windows family下开发的，对于可移植性的要求几乎没有，但是对于国外随着计算机技术的发展而沉积下来几十年的软件系统可就什么平台下的都有了。对于这些遗留系统，是在那种环境下，才有了java可移植性的优势。

如果那天microsoft一统天下，unix family死光光的话，java才可能真正没有什么竞争力了。
 02/06/05 12:14 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 anihclmu   可以暂图一时，大不了重新再来嘛！
 02/06/05 12:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  写论Java的可移植性--的目的何在
我写这些文章的目的，并不是故意和别人来唱反调，表现自己的独特观点。
我只是觉得，现在很多在技术上大家都认为成为定论的东西和观点，其实都不是那么准确和正确。例如Java,J2ee等等这些，许多人，许多公司把它捧得非常高，似乎无所不能，没有它什么都干不了，似乎没有任何缺点，但真的如此吗？

世界上的东西，一个特性，从这个角度看是优点，也许从另外一个角度看就是缺点，那么为什么不能来探讨一下缺点何在呢？

所以我才写这些文章来探讨一下事物的另外一面。
 02/06/05 13:13 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 holly_lee  您的目的没有错, 只是选择的点错了, 因为那是一个你不了解的东西....
 02/06/05 13:19 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 您的目的没有错, 只是选择的点错了, 因为那是一个你不了解的东西....
文章里那里写错了，请指教。
至于我懂不懂，是我的事情，与你无关。
 02/06/05 13:21 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 dengqizhou  任何功能都是有一定限制的，JAVA的可移植也不可能做到随心所欲，不过JAVA利用虚拟机来实现移植，微软的.NET照搬这一招。
 02/06/05 13:22 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 荒凉海   回复: 论Java的可移植性---不看会后悔的。。。
精辟！
 02/06/05 13:22 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 建议你少看些辩证法哲学，多看些技术哲学，形而上的理论，复杂性方面的理论，计算理论，高等代数等方面的书籍。这样对你更深刻地理解计算机有帮助。
thanks
 02/06/05 13:27 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 赫赫，老兄不能只站在WINDOWS程序角度说问题
但是主流的unix其实只有那么几种，而且都相对比较稳定。何况在unix上实际上也存在同样的问题，那就是那么多的unix平台上的虚拟机没有人统一开发，最后造成的结果就是使得java的可移植性名存实亡。
还有一个问题没有谈到，就是jdk的不同版本也使得实际的移植非常困难。
我个人认为，从长远来看，移植是不可能的。
 02/06/05 13:35 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  是的，确实如此
 02/06/05 13:36 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 可以暂图一时，大不了重新再来嘛！
可是问题是，现在许多项目，甚至许多大型项目，盲目地采用这些技术进行开发，将来会带来多大的问题和损失？
一旦有一天Java技术被认为是有缺陷的，需要多少人力来修正？
 02/06/05 13:39 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilingleo  回复: 写论Java的可移植性--的目的何在
呵呵，领导嘛，总会考虑一些好听的东西，现在流行什么，就上什么，不足为奇的。
 02/06/05 13:43 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  错，恰恰相反，当操作系统出现之后，程序员的想象力才被彻底释放出来。
在有操作系统之前，大部分程序员都是女的，因为那时的程序直接在硬件上作，既枯燥又乏味，直到第一个操作系统IBM的SYSTEM360出现之后，情况才慢慢改变了。
 02/06/05 13:43 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  哈哈哈，扯得太远了。
 02/06/05 13:45 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 原教旨  高手呀！
悔人不倦……
 02/06/05 13:51 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  反正闲着也是闲着
 02/06/05 13:54 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 joy_wind  忍不住要说两句...
看了楼上的文章忍不住要说两句。
兄台的许多言论可以说是毫无根据的（恕我直言）：

--〉Java的一大特点是其可移植性，也就是跨平台性，一处编写，到处运行。(Write once,run anywhere）。问题是，在实际的系统中，究竟有多少系统是需要这个特点的呢？...

在我们国家确实存在计算机系统平台种类单一的问题，因为我们国家计算机应用比较晚，基本是window横行时计算机才在我们国家里得到一定程度的普及；而在国外，macintosh,linux,unix,os/2和主机应用程序等等应用的还是相当广泛。即便在国内，在企业级应用上面也存在着大量异构的环境，比如电信、银行、航空等行业的应用。我们许多开发人员都是window桌面应用开发出身的，真正构建大型企业级应用的开发人员还是少数，所以许多人感觉身边都是windows系统，从而java的特点根本成了多此一举，这是可以理解的。

--〉就是Java语言无节制地使用系统的资源...
这句话毫无道理，让人发笑...

-->所以在使用Java时，编程越死板，系统性能反而越好...
看来你是主要从事编程的喽，java系统所带了的分析和设计的好处你根本就没体验到。事实上，难道这不是java给编程人员带来的福音吗？你不用再操心指针、事务控制、多线程通讯等等方面，多美妙的事情啊！

不想在这里再重复你的原话了，直接说吧：j2ee的内容很多，但并不复杂，如果说它复杂，那是因为它面向的应用复杂的原因。记住一点，它是面向“企业级”应用的，不是面向建两个表、做几个表维护界面或者查询就完事的那种数据库应用的。他要面对mainframe、cics、os/2、mq、tuxedo、weblogic、websphare、windows9x,soloris、AIX等等之类的软硬件环境，不“复杂”行吗？

最后我想提醒一句，虚拟机并不是java的独创，很久以前就有采用虚拟机的语言，最著名的就是smalltalk，在国外，用smalltalk的人多的是，利用smalltalk搭建的大型应用也多的是。.net似乎也在模仿这一点。
 02/06/05 14:03 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 忍不住要说两句...
--〉就是Java语言无节制地使用系统的资源...
这句话毫无道理，让人发笑...
：这个主要是指Java中的实例只管创建，不管回收。回收的工作交给虚拟机来做，这样做的结果就是系统的资源使用和虚拟机的回收机制有关，和虚拟机的具体实现有关。


-->所以在使用Java时，编程越死板，系统性能反而越好...
看来你是主要从事编程的喽，java系统所带了的分析和设计的好处你根本就没体验到。事实上，难道这不是java给编程人员带来的福音吗？你不用再操心指针、事务控制、多线程通讯等等方面，多美妙的事情啊！

：美妙的事情有其不美妙的一面，从局部来看，编程确实简单了，但这是以把许多问题掩盖起来为代价的；从总体上来看，正是由于细节的过分简化，带来了总体上的过分复杂和问题。程序员不操心的事情全部交给了虚拟机，结果系统的稳定性和性能就非常依赖于虚拟机了，可是虚拟机对于我们又是不可见的。当虚拟机出错时，该怎么办？
 02/06/05 14:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 忍不住要说两句...
--〉就是Java语言无节制地使用系统的资源...
这句话毫无道理，让人发笑...
：这个主要是指Java中的实例只管创建，不管回收。回收的工作交给虚拟机来做，这样做的结果就是系统的资源使用和虚拟机的回收机制有关，和虚拟机的具体实现有关。


-->所以在使用Java时，编程越死板，系统性能反而越好...
看来你是主要从事编程的喽，java系统所带了的分析和设计的好处你根本就没体验到。事实上，难道这不是java给编程人员带来的福音吗？你不用再操心指针、事务控制、多线程通讯等等方面，多美妙的事情啊！

：美妙的事情有其不美妙的一面，从局部来看，编程确实简单了，但这是以把许多问题掩盖起来为代价的；从总体上来看，正是由于细节的过分简化，带来了总体上的过分复杂和问题。程序员不操心的事情全部交给了虚拟机，结果系统的稳定性和性能就非常依赖于虚拟机了，可是虚拟机对于我们又是不可见的。当虚拟机出错时，该怎么办？
 02/06/05 14:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 原教旨   嘿嘿，我也瞎说两句，您别见怪
论Java的可移植性

>Java的一大特点是其可移植性，也就是跨平台性，一处编写，到处运行。(Write once,run anywhere）。
>问题是，在实际的系统中，究竟有多少系统是需要这个特点的呢？
很多的，特别是对做企业级产品的公司，很难指望用户那边没有异质平台，而用户与用户之间软硬件平台有差异就更有可能啦。传统的做法是为每个平台准备一个版本，这是需要一定成本的。
>可移植性的获得，是以编程灵活性的丧失和性能的损失作为代价的。
何以见得？论证一下？
当年C语言也是以可移植性而著称的，在绝对值上它相对汇编和机器码的灵活性和性能的是可能有损失的，但成熟编译器的代码优化能力已经达到或超跃中级ASM程序员的水平，只有极少数情况下并且程序员水平够高才需要关心这种损失，而c带来的开发效率提高确是多数据情况下大家都关心的。
后来出了C++，又是一场c++ vs c的性能论战。
哈，现在是java vs c++，有趣。

>为什么这么说呢？要保证可移植性，Java编写的程序必须通过虚拟机和操作系统进行交互，
>再和硬件进行交互来进行，
首先，理论上对于Java编写的程序未必需要通过虚拟机和操作系统进行，比如国内我知道上海交大图书馆有几台java station，有兴趣的同志可以设法去玩玩看。
另外很多操作系统本身就运行的一种虚拟机中，比如windows nt的hal就相当于一种虚拟机，而它的多数应用程序则是通过win32环境子系统与操作系统进行交互的。

>这样整个系统的性能实际上取决于这样几个方面：
>1。操作系统对硬件的支持程度
>2。虚拟机对操作系统的支持程度
>3。Java程序对虚拟机的支持程度
>4。上述三者相互之间的配合程度
其实影响力最大的因素并不是这几个方面，最大的是程序设计的水平，比如FreeBSD5.0的tcp/ip栈能够在一块千兆网卡上跑出单tcp连接900M的流量，而目前还没听说别的哪个栈有这么狠，而这并不是因为该操作系统对该硬件的支持程度特别高，而是人家程序写得就是牛。
我所知道的应用里有一个很经典的例子，该应用的一个主要功能代码需要访问上千次数据库才能完成一个计算，这时候再高档的硬件，再好的操作系统对系统性能的提高恐怕也比不上对这段代码设计的优化吧。另一个例子是有一数据库优化大牛，为美国一个连锁超市的核心业务做了一下优化，使使用最频繁的一条sql执行时间从0.1秒缩短到0.03秒，为此该超市给他一大笔钱(听说是1000万，不过懒得去查了)还发了一个年度大奖给他，真是名利双收呀。

>而最重要的是第四者，也就是三种调用关系之间的配合程度，
>可是遗憾的是，操作系统在设计时，不会考虑到以后会有虚拟机在上面运行，
>所以第二种关系的协调实际上是矛盾的。作为虚拟机来讲，
>它需要获得对操作系统资源的最大可能的控制，而作为操作系统来讲，
>出于安全等方面的考虑，它必须限制虚拟机对于自己资源的控制。
>所以任何程序，当它运行在操作系统上时，它都不可能象操作系统一样获得对于硬件的控制权，
>而且操作系统一定会设法来限制它对于资源的使用，这就是虚拟机和操作系统之间必然存在的矛盾关系。
java虚拟机本质上就是一个应用程序，也完全可以做到核心模式下去运行，操作系统对它的限制跟其它性质的应用程序或者内核模块是完全一样的。

>Java语言的设计，是站在虚拟机上来考虑问题的，所以它的设计风格，
>从操作系统的角度来看，是很难接受的。
>具体的表现，就是Java语言无节制地使用系统的资源，
java语言哪里无节制的使用系统的资源了？具体一点，哪些资源？内存？硬盘？CPU？FileHandle？SOCKETs？网络带宽？线程？进程？窗口？或者windows gdi资源？
估计没有用过java命令的 -ms -mx -ss -rs等参数？

>而系统的资源对于操作系统来说，是至关重要的。
>这些资源，主要是指对于内存的使用。当每一段程序都盲目的使用系统的资源时，
不管什么系统，程序要是无节制的使用资源都是一个巨大的问题。
>系统的资源就会枯竭，操作系统最后无法完成资源的调配，系统就崩溃了。
>如果操作系统本身写的比较好，那么这种情况会少一些，而如果操作系统本身就不太稳定，那么这种情况就非常常见了。
操作系统不能提供资源时不应该崩溃吧，而应该拒绝进一步的资源请求吧。比如内存还有1M，你要申请10M，不过是用java还是c lib或者系统调用都会失败的吧。


>在这种情况下，虚拟机作为Java程序和操作系统之间的中间人，
>需要调整和协调两者之间的关系，使系统处于一个稳定的状态，
>可是Java程序究竟写的如何，是由具体的程序员来决定的，
>所以虚拟机在一个假设的基础上进行协调和调和。
虚拟机为什么要做和事老呢？应用找它要，它就找操作系统要不就完了？事实上用户可以制定虚拟机使用内存的上下限，超过限额就拒绝进一步的内存要求，完全不存在猜测的问题，对于防止资源滥用更是大有帮助。你所针对的应该是指自动垃圾回收机制吧，有了该机制，程序员可以少花很多精力在memory leek分析上，程序员可以创建一个对象就用而不保存对它的引用，这在没有gc时会引起涉漏，但有了gc该对象占用的内存就自动变成free的了，它会根据预定义的策略选择在适当时候真正替程序员去做free的工作。用过c++做大程序的话，对于gc能节省多少开发精力应该很有感觉。
另外，现代的程序开发环境通常都在其runtime中带有内存管理设施，程序通常并不是直接做系统调用请求或归还内存，而是直接在堆栈上使用，当程序调用库中的malloc/free或者对象/变量超出life cycle时内存管理设施都得跳出来做内存管理，这些工作与gc所做的并没有本质的区别。

>所以要有可移植性，就必须有虚拟机；有了虚拟机，就必须协调程序和操作系统之间的关系；
>要协调这两者之间的关系，就必须限制编程的灵活性；
>限制了编程的灵活性，就必然降低了系统的性能。
>这就是一个逻辑上的怪圈。从可移植性出发，得到了编程灵活性的丧失和系统性能的降低。
首先前提就不成立，其次限制灵活性跟降低性能有什么逻辑关系吗？
java对编程灵活性的限制在某程度上是有的，主要是强制面象对象和限制了低级操作等，比如raw socket或者直接硬件访问之类的，但如果需要还是可以通过jni来得到的。
但对于灵活性应该先下一个定义，事实上有了object根和gc，程序员写程序时可以更方便更灵活，不再需要花很多精力去琢磨有没有搞内存涉漏。比如以前建立一个对象调用一个方法即释放，需要定义一个变量，再建对象并保存到变量，然后访问对象，然后释放对象，然后将变量置空以防不测，现在只需要创建并调用即可，传统方法也可使用，哪个更灵活？

>所以在使用Java时，编程越死板，系统性能反而越好，这就是一个非常奇特，又非常实际的问题。
数据来源？另外，给死板下个定义先？

>可是编程太死板了，又难以构建出一个庞大的系统来，那么怎么办呢？
>于是就强调分工，强调层次，最后搞出一个J2EE的东西来，如同《封神演义》中的姜太公，
>各种技术一一到位，这下子天下太平，似乎可以毕其功于一役，
>把所有问题一下子全部解决。所以J2EE非常复杂，复杂得几乎让人望而却步。
j2ee是什么？这些技术可不是java发明的哟。想做企业级开发，其复杂度自然不会低。jndi可比x.500简单得太多了。更不要说j2ee之与com+了。

>所以强调在J2EE的框架下进行开发，这样子编程就非常死板，死板到了极点，
>就是第一行写什么，第二行写什么都定了下来。大家可以看看那些例子，那个不是如此呢？？？
是吗？实际写过东西吗？比如blue print和jive两个比较常见的例子，它们第一行，第二行都一样吗？
是不是觉得写c程序都得main开始，windows程序都得从winmain开始也死板到极点？

>但是这并不是真正解决问题的方法，因为这样做只是在破洞上打了一个又一个补丁，
>并不是从根本上解决问题的方法。为什么不能从根本上解决问题呢？
>根本的原因是在于对于自己提出的技术的盲目维护和盲目信仰，
>宁愿在上面打上漂亮的补丁，也不愿从新开始进行设计。
你所说的问题和破洞下个定义先？

>Sun与Microsoft之间的争夺，实际上是虚拟机和操作系统之间的矛盾的表现，
>这种矛盾，争夺的是对于硬件的控制权，争夺的是一个对于市场的垄断地位，
>从根本上讲，是经济利益的争夺。而Java语言，就成为了这种争夺的牺牲品。
至于sun vs ms，是平台之争倒不假，是利益之争倒不假。不过跟硬件控制权云云没什么关系。

>从技术上来讲，Java语言被过分地抬高了，这种抬高掩盖了Java本身的矛盾和不足，
>而这种不足在大型系统开发时会以其他形式表现出来，就是系统的性能不足和系统崩溃。
java在真正大型系统中的成功案例很多，自己去看看再来说事吧。

>各种实现J2EE标准的厂商和产品，其实也是相应地做一些妥协而已，
>这些妥协，都只能在现阶段暂时解决这些问题，从长远来看，
>它们将带来越来越多的矛盾和问题，最终将导致依赖于此的现存计算机系统的完全崩溃，
>就如同互联网浪潮泡沫的崩溃一样。
听得我好怕怕哟。

>结论：Java提供的可移植性，是一个美丽的谎言，整个计算机行业将为此付出惨重的代价。
ibm/sun/weblogic/oracle/sap……都是猪头在当CTO呀，居然都被这么容易看穿的谎言给骗了。
 02/06/05 15:09 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 holly_lee  嘿嘿, 请看前面原教旨老兄给您回到贴, 说得很清楚了.
至于您懂不懂, 的确不是我的事, 不过照这个逻辑, 我认为您懂不懂也一样与您无关
 02/06/05 15:17 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  写的好！！！
 02/06/05 15:35 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 jes  回复: 论Java的可移植性---不看会后悔的。。。
从另外一个角度看问题。这种精神值得大家学习。
 02/06/05 15:41 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  有够耐心，真是毁人不倦啊，呵呵。
 02/06/05 16:25 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   在Windows 2000和XP上可以运行Win31上开发的商业系统。Java号称要做到“处处使用”，但是并没有提供Windows的全部功能，怎么取代Windows程序，一个小脑袋顶着一个大帽子。.Net也用中间语言，执行前再在目标计算机上编译成机器码！Java还有什么优势？
 02/06/05 21:50 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：