精华区 [关闭][返回]

当前位置:网易精华区>>讨论区精华>>编程开发>>● Java>>技术言论>>转贴csdn JAVA无用论

主题:转贴csdn JAVA无用论
发信人: skyyoung@GZ()
整理人: zjxyz(2002-01-26 13:38:08), 站内信件

标  题: 转贴csdn  JAVA无用论 
发信站: 网易虚拟社区 (Wed Nov  1 09:49:09 2000), 站内信件

===============
(问题)
JAVA无用论 2000-10-24 

1. 写这篇文章的目的 
学了一些关于Java的东西,个人认为它很不好用。为了减少上当人数 
特写此文。 
尽管 java 宣称它是100%面向对象,而C++不是。但是宣称100%面向 
对象本身就不是什么面向对象的思想。面向对象的本质目的是提高生 
产率。讨论一种语言是否100%面向对象就好像讨论我们的社会性资性 
社一样滑稽。其实学习面向对象不一定非要使用java不可。我反而认 
为120%面向对象的C++是不错的选择。 
Java号称跨平台,其实这是只一个梦想,也不妨用骗局这个词来形容 
。软件的移植性仅仅和虚机相关吗?照此理论是不是可以说符合IA32 
体系的软件在任何IA32体系上都能正常运行。那我怎么没看见SCO: 
:lf 在 NT上运行?显然,除了虚机,软件二进制规范(执行文件格 
式、连接方法)、运行时间库和系统调用也是软件移植问题因素。而 
java规范中显然不包括完整的运行时间库和系统调用,甚至二进制规 
范也有不兼容的地方(比如本原接口和固有接口)。软件总不能脱离 
它的运行环境,不兼容就从这里开始。 
要提高软件生产效率。应当认认真真的研究系统结构、二进制规范、 
系统调用结构才是解决问题的方法。靠概念游戏这种投机取巧的方法 
是行不通的。 
我说java不好,甚至不必对其侧目,你信吗?我估计信的人不多。我 
只是想说“上当之后别怪我没说”。 
另外如果您在Java中发现了甜头也不妨告诉我。互相学习吗:)。 
2. Java究竟是什么? 
Java是一种虚拟硬件系统结构,是一种软件二进制规范,是一种编程 
语言。当我们看到Java一词时,它可能表达上述三个含义钟的任何一 
个。尽管这三个东西可以独立存在,不过实际上他们总是在一起出现 
。所以也很少有人分的那么明确。使用Fortran语言编写Java虚机上 
的代码理论上是可行的。但是有谁乐意做这件事呢? 
作为虚拟硬件体系结构, 
Java虚机和ALPHA、PowerPC、SPARC、IA32、51、960是同一概念上的 
东西。也许您会奇怪?他们怎是同样的东西呢?IA32不就是PIII、PI 
V那一大块吗?其实不然、我们知道386、P5、P6、P7的内部结构非常 
不同。属不同的微体系。但是他们实现了相同的IA32指令集合。IA32 
也不一定非要通过硬件实现,通过软件也可以。这种软件CPU产品广 
泛出现在操作系统和CPU密集软件的开发、调试工具上。主要用于在C 
PU出现之前调试软件。Java指令集同样也可以通过硬件实现。只是在 
半导体工业激烈竞争的时代,没有大公司(含SUN)愿意把这么做。 
SUN常常说M$很害怕java。他们之间的确存在很强的竞争关系。倒不 
是Java高级语言的问题,我认为是Java二进制规范和 Windows操作系 
统存在竞争。不妨考察Java中的(.class文件格式、装入方法、执行 
过程、JDBC接口、J3D接口)和Windows中的(PE文件格式、DLL文件格 
式、装入、连接方法、ODBC、Direct3D)。就知道竞争多么强烈。和N 
T/IA不同。Java.exe执行程序包含虚机规范和二进制规范。在NT/IA 
中是分离的产品。 
人们总喜欢把Java高级语言和C++类比,他们之间的确存在很过相似 
的地方。不过我认为C++和Java不存在什么竞争。它们使用在不同的 
场合。他们的区别(内存管理、对象类型、线程规范)决定他们的用 
途。用形似而神不似来形容C++和Java吧。仅从高级语言方面来看。J 
ava真正竞争来自ECMAScript 。也就是JScript和VBScript。 
3. Java虚机和IA32比较 
Java VM和IA32最大的区别是Java VM的主要实现不考虑效率问题。由 
此派生出寄存器少,指令结构简单(同样功能生成的程序代码长), 
寻址空间小,寻址方法少、数据类型少等。除了上述问题,Java VM 
没有涉及指令(显式或隐式)并行问题。 
3.1. 基本特性差别 
3.1.1. 数据类型比较 

Java VM 
IA32 
整数类型 
byte 
short(16bit) char(UnionCode) 
int 
long (64bit) 
{不存在无符号算术运算指令,另外注意这里没有boolean类型} 
byte 
Word(16bit) 
DoubleWord(32bit) 
QuotaWord(64bit) 
DoubleQuotaWord(2*64bit) 
BCD/PackedBCD 
BitField 
{存在有符号和无符号两种运算指令} 
浮点类型 
float(32bit) 
double(64bit) 
float(32bit) 
double(64bit) 
long double(80bit) 
Packed double(2*64bit) 
地址 
returnAddress* 
8bit , 16bit , 32bit , 48bit都有 

没有显示的看到returnAddress 
类型的宽度,不过。通过指令goto(0xa7)和goto_w(0xc8)来看。retu 
rnAddress是可以是16位或32位的。 
关于double和Long的原子问题:在目前的java规范中,double和long 
作为两个独立的32 位数据独立存取。这样可能产生同步问题。历史 
上Intel的CMPXCHG8B(Pentum pro以上CPU提供)指令就存在过类似 
问题,一度被指责是CPU设计问题。好在CMPXCHG8B很少使用,没有造 
成什么事故。 
3.1.2. 指令集 
指令类型 
JavaVM 
IA32 
Load/Store 
1) 数据和运算栈之间单个移动 
2) 常数移入运算栈 


1) MOVE 
2) CMOVEXX 
3) 交换,琐操作 
4) PUSH/POP 
5) PUSHA/POPA 
6) IN/OUT 
元算指令 
add , sub , mul , div , neg , rem , shl , or , and , xor 
比Java多多了,主要多在显式并行上 
类型转换 
基本类型之间可以互相转换 
有(由于类型很多,转换指令也有很多) 
方法调用 
4条指令 
一大堆,主要多在权限切换(调用门)、长短跳传不同上。 

3.1.3. 异常 
虽然JavaVM有异常的支持,不过很简单。它不区分中断、陷阱和故障 
。也不能明确指出出错代码的PC,并返回那里重新执行。 
3.1.4. 执行态 
Java VM没有用户态和系统态执行区分。当然也没有MMU(管理内存分 
页、分段的内存管理单元).除非被Java高级语言限制,java VM汇编 
代码也能完成一些恶意操作。 
3.1.5. 小结 
总而言之,Java VM很简单。SUN总是认为通过编译优化Java可以达到 
C++速度。显然是谎言。如果要编译成本地代码,显然要丢失移植性 
。如果不编译成本地代码,效率问题如何解决?有一种及时编译的设 
计。对于很小的应用也许可行。对于规模的应用呢?要知道优化编译 
很费CPU和内存。像IA64体系的优化方案,要编译很多遍才能优化完 
成。要运行时刻编译是不是天方夜谭。 
4. Java高级语言和C++、JScript比较 
4.1. 效率,谎言 
很多书上写Java是很快的语言。这时一定要看清楚是比谁快。语句传 
了几本书难免有些误差,比较对象经常有意无意丢失。一般认为Java 
比JScript快。的确快很多,不只十倍。我也承认Java比JScript快。 
但有人说Java和C++效率接近。这就是骗人了。他们也能做出试验证 
明,试验结果好像也能证明结论。他们的实验大概都是形如这样。 

Java, C++测试代码: 
for ( I = 0 ; I<100 ; I++ )
{
RemoteCall( I );  //外部调用,调用一次用1s。

结果:
Java 102s , C++ 100s。
结论:
Java达到了C++ 98.0%的效率。
这种测试违背了测量学中要把测试对象放到主要矛盾上这一基本原
理。方法的不正确当然带来了测试结果的不正确。有本事比比
for ( I = 0 ; I<10000; I++)
{
y = x * z;  //由Java语言或C++语言实现执行体   
}
我的结果是170倍。也就是PIII变成了286。如果使用指令并行优化
,C++和Java的速度差异可以达到千倍以上。想用一下8088吗?
4.2. 功能缺失导致代码膨胀
简单的说,Java比C++缺少编译预处理、缺少运算符重载、多继承和
类模板。我认为取消这些概念很粗暴。和C++不同。对于大规模编程
来说,Java的代码量不会比C少多少。甚至由于类型约束太强。有可
能比C的代码量还大。
Java常称多继承比较困难,所以要取消。而且使用实现接口的方法可
以代替C++的多继承。但是,实现接口要自己写所有的接口实现代码
。不嫌烦就慢慢写吧。
为什么要取消运算符重载?真是不可理解,既简单又好用。它居然说
难,且容易造成混乱。
总之,处理这几个大方向的问题,还有很多小问题。据说AWT不好用,
感觉他们为了完成任务写程序。
4.3. 简单的骗局
自古便宜没好货。Java总是宣扬Java如何简单,主要宣扬的好处是垃
圾自动收集和线程同步。其实不然,由于Java没有释放关键字。使得
不能及时释放或定时释放不必的数据。要知道能够分配的不只是内存
,还有数据库句柄、文件句柄、结果集等。这样不得不绕来绕去的完
成这些任务。其实C++的析构函数是自动调用的,也不用自己手动掉
用。遇到一些特殊情况,C++也能很好的解决。
也许java的线程比较简单吧,不过C++中也可以继承线程类。由于本
人没有涉及线程编程。这里不好乱说。
5. Java的兼容性
相对本地代码来说,Java程序的确移植性比较好。归其原因不外有二
。一来Java虚机只一种(不像天下有很多种CPU),二来Java二进制
规范只有一种(不像这么多种操作系统)。但是,Java代码真的可以随
心所欲的移植吗?其实不然,上述两条中的任何一种不再满足,都会
影响ByteCode的移植性。
现在,Java的主要版本已经有1.0 , 1.1.7 , 1.2(2.0)三个。更残酷
的是1.1.7和1.2不兼容。一个很著名的例子。Websphere不能在Java1
.2上运行。另外WebLogic不能在1.0上运行。
java的二进制规范呢?jview( MS java)就自立门户。他的.class装
入方法就和java for win32不同。另外它提出了其他的本地代码连接
方法。显然这里也会造成不兼容。
除了上述两条重要的原因,还有就是程序的运行环境。比如操作系统
是否区分文件名的大小写。数据库是否中调用都能返回执行成功。EJ
B的代码是否有EJB 的运行服务器。等等。
6. 在精通Java之前否定Java
本人只是对Java略知一二。为什么就非要否定java呢。其实,从一般
科学观点审视java。就会发现其中的问题。
6.1. Java代码不符合从简单到复杂的认识规律
代码比较:
Java Code Example:
import java.applet.*;
import java.awt.Gaphics;
public class HelloWorldApplet extends java.applet.Appple
{
public void init(){
resize( 200 , 150 );
}
public void paint( Graphics g){
g.drawString("Hello World" , 50 , 100);
}
}

C++ Code Example:
#include
class Hello :public Applet
{
public void init();
public void paint(Graphics g);
};

Hello::init()
{
resize( 200 , 150 );
}
......

我们看到,java开始就要求写函数的实现。而C++先要描述轮廓。再
写函数实现。
6.2. Java对从一般到特殊的思维方法支持的不好
从一般到特殊,是重要的思维方法。对应到计算机学科就是继承。而
今多继承的概念已经广为流传。比如我们说“小花猫”,就是继承“
小”、“花”、“猫”三个概念。如果在字典上看到小花猫这个词,
它一定不再描述“小”、“花”、“猫”这三个概念,而是继承他们
。但是java只能继承其中的一个。对另外连个还要仔细的描述。写起
来是不是很烦。
6.3. Java设计不尊重“任何事物都有产生、发展、消亡的过程”这
一自然规律
Java没有析构函数。这一点很讨厌。我只想重复一遍“对象不都在内
存空间中”。
6.4. Java 不能表达少数类之间的紧密相关
java要求每个类使用一个文件。这种实现可能和它的自动编译执行方
式有关。注意这种限制不是实现上问题,而是规范中的语句。但是这
种方法合适吗?请看下面C++的例子。将这两个类分开为两个文件是
否真的好读?
struct menuitem{
String strX;
int   iIndex;
};

class menu{
menuitem item[100];
... ...
};
和这种情况类似,javadoc也不能对紧密相关的数据进行描述。
至于类模板。java更是不支持。自己一个一个的慢慢写吧。
6.5. 批判Java的批判
Java要诞生,必须批判原有C/C++语言的缺陷。列举其中一二。
“C/C++语言中的整形数据不限制长度。这样一来当程序从32位系统
移植到16 位系统时会造成错误”。可是仔细想想。这种移植的概率
究竟有多少?
“Java不像C/C++,它完全不支持指针”。按此理论,同样不支持指
针的Fortran77和basic是不是也很强壮。
“Java不允许隐式类型转换”。如果整形和浮点数据之间的转换都要
写一下,是不是很烦。
“联合体、全局变量他们都不是面向对象的东西”。面向对象一直就
没有什么定义。本着好用的东西就是好东西的原则,保留这些概念也
不错。像M_PI这类的常量或者项目中的确全局相关的准常量,使用全
局变量是不是很方便?至于联合体,是优化存储效率用的,像 Java
这种不考虑效率的语言自然不会支持。
“java存在比C++多的运算符”。好像是多一些,他们是(字符串 +),
> >> , (boolean)& and &brvbar; , instanceof。但是我们分析一下。由 
于java不支持运算符重载,只好单独实现(字符串 +)。由于java 不 
区分有符号和无符号数据,所以使用>>>来表达无符号右移、由于jav 
a中的boolean和整形之间没有联系,又不支持运算符重载,所以对bo 
olean类型单独实现& and &brvbar;。至于instanceof的确是Java 独创,不 
过这个运算符的用处还要考虑。我在引用某变量时居然能不知道它的 
类型? 

6.6. 兼容以不兼容为代价 
使用java 必须一切从头开始。java不能继承原有的工作。而且它也 
不能很好的和其他语言混合编程。这就和C++区别大了。首先C++继承 
了大部分C语言代码。其次,C++可以和Pascal , Fortran , Basic, 
T-SQL等其他语言方便混合。尤其方便的是ASM语言和 C++混合。发挥 
不同语言的长处。俗话说“朋友多,天地宽”吗。而 java只能孤军 
奋战了。 
7. 结束语 
写这篇文章用了一天半的时间。又在Java上花了这么多时间,真是心 
痛。但愿有些效果。 

=================================
(回答)

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秒,这就说j
ava慢?好,那么那个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的问题。是
采用如何的方式学习和应用语言开发的问题。在工程里面说明一遍,然后再在he
ader里面写一清遍,恐怕算是浪费体力吧。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可以访问交易系统,ja
vacard可以在sim卡上跑,corba可以调用任何支持corba的东西,socket可以调用
任何支持ip的语言,rmi虽然只能用java,但是可以非常透明的得到实例,这是其
它语言不具备的优势,适合网络分布计算。呵呵,这些只是非常普及的java技术
之一小部分,它虽然不是什么崇高的理论,但是起码它能让许多计算机在一起工
作,为应用服务,这才是我们最关心的问题。

7.偏系统底层开发,我宁可用C,中间层开发倒是java,界面用些简单工具就算了
。至于c++,恐怕只是当初在接触面向对象时看到的一个诱人的梦了。



看了这篇贴子,有些感发,断断续续写了4个小时,才将思绪理的清楚一点,望各
路高手指正。
oicq: 1766598
mail: [email protected]

--
※ 来源:.月光软件站 http://www.moon-soft.com.[FROM: 202.105.40.210]

[关闭][返回]