看看C#与Java相似之处的对比
发布时间:2008/9/11 0:00:00 访问次数:597
java:无可争辩地具有c++所有的精华
在比较java和c#的时候,你不可能不注意到它们诸多的相似之处,这在某种程度上要归结于它们共同的来源:c和c++。但是,当gosling和他的同事们坐下来创造java的时候,他们不仅吸取了c++的能力,而且更重要的是,他们减掉了一些无用特性,后者让c++更容易出错误而且更难学习。c#的设计者加入了很多c++的特性,而java也加入了这些特性,但是c#却没有去掉c++的最糟糕的一些特性。其结果就是这样一门语言,它仍然为所有人提供了所有的特性,但其结局是内部冲突不断,而且过于复杂。
散漫的句法缺陷
最容易找出的错误是流控制和句法。c#提供了goto command,将其作为更改程序执行点的机制。自从edsger w. dijkstra在1968年出版了他的《关于go to陈述式害处的考虑(go to statement considered harmful)》。goto语句导致代码难以调试,而且很难被测试工具处理。
在另一种不同的情况下,操作符过载同样也有很大问题,只不过层次不一样罢了。当“+”根据操作数的类型而代表任何东西的时候,代码的功能就不再透明,难以预料的副作用就会发生。
c#在安全上的削弱
c#有一个用于将代码区域标示为不安全的简单机制。在这些不安全的区域里,java以及后来的c#安排到位了一些安全措施,用以防止程序员直接修改内存位置,以及使用点运算,但是这些措施是值得怀疑的。在使用具有垃圾清理功能的高级语言时,如果下到内存地址这一层,就会把对象/内存之间有意作出分离弄混。错误就会容易出现,调试成了恶梦,缓冲区溢出再次抬头,c和c++里著名的安全漏洞再次现身。
c#还允许对主机系统上本机库的简单访问。这个与非.net对象相结合的访问同java本机接口(jni)所提供的功能类似,但是它更加危险。jni被设计用来小心地限制java代码以及本机代码同已定义好的接口之间的交互操作,.net使得调用本机对象文件变得极其简单,结果导致开发人员在做这的时候,无法意识到他们在这一过程中把平台的可移植性也扔出了窗外。
soap的集成
c#,及其更大的扩展.net,已经同soap web服务紧密地集成在一起。soap是使用xml指定参数和结果值来进行远程过程调用的好标准,但是它并不是唯一的方式。利用用于web服务的外部库能够允许java开发人员轻易地更改其web服务的风格,使其成为soap、xml-rpc,或者什么还没有发明的东西。当然,c#的开发人员总是能够选择将外部库用于soap的web服务,但是由soap标准的紧密集成所造成的限制要比它能够做的东西更多。
所有者的恐慌
c#里最令人恐慌的特性可能就是其所有者了。微软已经为将c#和.net用于非windows平台进行了精心的展示,但是这在很大程度上还只是作秀。其用于非windows平台的clr是问题多多,错误多多。它通过ecma标准化过程来运行c#??这一步连sun也不敢在java上迈出。其担心来自于微软对此可能封锁的程度,如果它愿意的话。微软已经申请了一个专利,以排斥他人编写第三方的crl,例如mono计划。如果微软决定对免费的c#和.net社区施压,它就有能力拿票子和法律的大棒把其开发活动赶回到win32平台??当然这也不是它想看到的情况。
而java语言则相反,不是ecma标准的,真可惜sun没有遵从这一标准。但是,它是可以实现的,而且没有专利的阻碍,其虚拟机和核心类库都有来自第三方的开放和封闭源代码的实现。c#看起来是免费的,其实不然,而java看起来限制很多,但是它能够依据法律通过免费的途径来实现。
最后,我从来都没有想到我会说这个,但是java具有更好工具的支持,即使是在考虑到集成开发环境(ide)的情况下。visual studio .net是一个很不错的ide。它代表了多年的努力,而且特性很丰富。但是,eclipse ide包括了对java的支持,它在稳定性、易用性和所提供的特性上超过了visual studio。ibm对eclipse的贡献举足轻重,而且如果你信奉原来的软件格言“创建一个扔掉的(build one to throw away)”,那么你可以把visual age作为第一个(被抛弃掉了的)尝试。对于使用c#的开发人员来说幸运的是,eclipse的.net版本正在开发中。
不是那么差,但是还不是java
客观一点评价,c#里并没有什么很恐怖的东西。它没有visual basic里的那些很恐怖的东西,而且它事实上也没有继承像c里的一些东西,而这些东西会让开发人员开枪却打中自己脚。但是,底线是,c#并没有做
java:无可争辩地具有c++所有的精华
在比较java和c#的时候,你不可能不注意到它们诸多的相似之处,这在某种程度上要归结于它们共同的来源:c和c++。但是,当gosling和他的同事们坐下来创造java的时候,他们不仅吸取了c++的能力,而且更重要的是,他们减掉了一些无用特性,后者让c++更容易出错误而且更难学习。c#的设计者加入了很多c++的特性,而java也加入了这些特性,但是c#却没有去掉c++的最糟糕的一些特性。其结果就是这样一门语言,它仍然为所有人提供了所有的特性,但其结局是内部冲突不断,而且过于复杂。
散漫的句法缺陷
最容易找出的错误是流控制和句法。c#提供了goto command,将其作为更改程序执行点的机制。自从edsger w. dijkstra在1968年出版了他的《关于go to陈述式害处的考虑(go to statement considered harmful)》。goto语句导致代码难以调试,而且很难被测试工具处理。
在另一种不同的情况下,操作符过载同样也有很大问题,只不过层次不一样罢了。当“+”根据操作数的类型而代表任何东西的时候,代码的功能就不再透明,难以预料的副作用就会发生。
c#在安全上的削弱
c#有一个用于将代码区域标示为不安全的简单机制。在这些不安全的区域里,java以及后来的c#安排到位了一些安全措施,用以防止程序员直接修改内存位置,以及使用点运算,但是这些措施是值得怀疑的。在使用具有垃圾清理功能的高级语言时,如果下到内存地址这一层,就会把对象/内存之间有意作出分离弄混。错误就会容易出现,调试成了恶梦,缓冲区溢出再次抬头,c和c++里著名的安全漏洞再次现身。
c#还允许对主机系统上本机库的简单访问。这个与非.net对象相结合的访问同java本机接口(jni)所提供的功能类似,但是它更加危险。jni被设计用来小心地限制java代码以及本机代码同已定义好的接口之间的交互操作,.net使得调用本机对象文件变得极其简单,结果导致开发人员在做这的时候,无法意识到他们在这一过程中把平台的可移植性也扔出了窗外。
soap的集成
c#,及其更大的扩展.net,已经同soap web服务紧密地集成在一起。soap是使用xml指定参数和结果值来进行远程过程调用的好标准,但是它并不是唯一的方式。利用用于web服务的外部库能够允许java开发人员轻易地更改其web服务的风格,使其成为soap、xml-rpc,或者什么还没有发明的东西。当然,c#的开发人员总是能够选择将外部库用于soap的web服务,但是由soap标准的紧密集成所造成的限制要比它能够做的东西更多。
所有者的恐慌
c#里最令人恐慌的特性可能就是其所有者了。微软已经为将c#和.net用于非windows平台进行了精心的展示,但是这在很大程度上还只是作秀。其用于非windows平台的clr是问题多多,错误多多。它通过ecma标准化过程来运行c#??这一步连sun也不敢在java上迈出。其担心来自于微软对此可能封锁的程度,如果它愿意的话。微软已经申请了一个专利,以排斥他人编写第三方的crl,例如mono计划。如果微软决定对免费的c#和.net社区施压,它就有能力拿票子和法律的大棒把其开发活动赶回到win32平台??当然这也不是它想看到的情况。
而java语言则相反,不是ecma标准的,真可惜sun没有遵从这一标准。但是,它是可以实现的,而且没有专利的阻碍,其虚拟机和核心类库都有来自第三方的开放和封闭源代码的实现。c#看起来是免费的,其实不然,而java看起来限制很多,但是它能够依据法律通过免费的途径来实现。
最后,我从来都没有想到我会说这个,但是java具有更好工具的支持,即使是在考虑到集成开发环境(ide)的情况下。visual studio .net是一个很不错的ide。它代表了多年的努力,而且特性很丰富。但是,eclipse ide包括了对java的支持,它在稳定性、易用性和所提供的特性上超过了visual studio。ibm对eclipse的贡献举足轻重,而且如果你信奉原来的软件格言“创建一个扔掉的(build one to throw away)”,那么你可以把visual age作为第一个(被抛弃掉了的)尝试。对于使用c#的开发人员来说幸运的是,eclipse的.net版本正在开发中。
不是那么差,但是还不是java
客观一点评价,c#里并没有什么很恐怖的东西。它没有visual basic里的那些很恐怖的东西,而且它事实上也没有继承像c里的一些东西,而这些东西会让开发人员开枪却打中自己脚。但是,底线是,c#并没有做