正确响应是甚麽？
/c*_%l3k|#o#x)pj|JAVA中文站社区门户\&O1_1v4i"N"n?
对于微软开发商.Net是个好构架你可以将许多事情交给微软体系结构去完成ASP.NET比ASP好ADO.NET比ADO和DCOM出色但有所差别C# 比C和C更好.Net最初版将在2001年某个时候可以得到因此你有足够时间准备但是可以肯定它将成为微软平台缺省(约定)开发环境如果您现在正在微软开发构架中从事开发工作将.Net元件采纳到你体系结构中肯定能够获得利益

W.]7K7e{
,Ht~!V WBEE{但是.Net平台几个期望目标极高但不能保证全部起步至少在短期内完成不了例如IL公共语言运行时在使开发者获益的前还有某些明显障碍需要克服想要把每种语言和元件运行时集成起来必须定义这种语言子集/超集并清晰地影射到IL运行时上和必须定义结构以便提供IL需要元数据然后和必须开发适用于两种编译语言结构(对象、部件等)编译器(从XML到IL和从IL到XML)集成到IL部件字节代码中同时还要生成对现有IL元件语言专用接口
Y
Bx&G2F n'lW-VJAVA中文站社区门户7{Oc!cL#J%p jg ]
这里还有些历史因由必须开发非Java语言到JavaVM众多桥梁如:Jpython、PERCobol、The Tcl/Java Project同时如果有足够兴趣几年前就应将Bertrand Meyes和些别Efel folk起放到Efel-to-Java VM系统中(几年后)只有Jpython 例外这些工具得到广泛采纳甚至在他们自己相关委员会里也是这样即使它们似乎能够提供种思路方法用你所偏爱语言为Java环境写代码(虽然不是整个J2EE构架)然而为什么还这样缺乏热情？人们犹豫不想承受从它们开发语言中将额外翻译工作加到目标构架上如果Java环境是目标人们通常会选择学习Java我预计对.Net也是同样正确人们将会选择学习C#和用这种语言写.Net部件 JAVA中文站社区门户pA^"VI{SQ

'D$P%LV&P;O%X2~另点要注意:基于.NetSOAP将用于分布式通信谨防性能损失SOAP基本上意味着在HTTP上XMLHTTP不是个高性能数据协议因此XML隐含个XML语法解析层也就是需要更多计算开销两者相结合会大大减少相对另种发信/通信信道事务处理速率XML是种非常丰富、十分强大发信用元语言HTTP是非常灵活可移动因此可以防止许多防火墙损失但是如果事务处理速率对你是优先考虑话请保持你选项打开 JAVA中文站社区门户)eq&jE2N2f
JAVA中文站社区门户;I(Zs$OA
对于Java和开放资源委员会 JAVA中文站社区门户Fj7}\Nx
JAVA中文站社区门户T i J:^'_#WTG6^
请不要把.Net作为微软市场竞争手段继续以你们喜爱方式理解.Net可能更容易接受但是.Net并不是种精巧标志而是微软策略重大转移将为其平台带来福音他们正在为使其它构架和平台在管理级上做得更好而奋斗提供有关自身成本和无缝集成方面有用可查询统计资料现在他们正努力把Java和开放资源自身所特有元语言逐步开放然后力图直接满足开发商需要在过去段时间里由于他们没有做好两件事情失败了如果你认为自己是Java和无资源平台福音传播者那么竞争性质就会改变
3wXUr-SF
2j:X^k&N8l
QJ另外微软IL运行时至少可能有个值得注意目标:就是清除编程语言进入结构框架障碍Java清除了平台障碍(当然在有限范围内例如你不能没有硬件资源来制作软件Software)但是为了用J2EE来作开发工作你必须在Java环境下工作而.Net是想让你使用你选择语言来建造.Net应用这是十分美妙尽管还有些大问题没有解决如:.Net中IL方式什么时候和是否会实际上变成广泛使用(工具)(如上所述)不管怎样这就表明了单语言J2EE方式存在弱点这个弱点重要性可以怀疑但是它依然存在因此它值得Java委员会考虑如果开发商真认为是这样那么就可以把力量放在Java字节代码生成器方面以适应非Java语言当然这需要组织和浓缩(汇总) JAVA中文站社区门户$Vu Y)_ Gn
JAVA中文站社区门户/]#uSoB^ yZ,Ln
再深入研究下J2EE立即可以得到些结论为了支撑该平台和.Net相较量优势首先XML支持要无缝地集成到结构框架中我们且不说将XML SAX/DOM语法解析器作为组标准服务或者在配置元件中扩展XML使用这里需要XML发信和操作处于随时可用状态公认做法是在JMS顶端用XML内容发信但是并不是所有平台都有这种设施XML空间是堆杂乱无章标准非关键原因标准API和DTD是你处理元语言时期望 JAVA中文站社区门户5P;cc%E"BR
JAVA中文站社区门户 t@L ]Dej!V
但是微软已经将SOAP放在基础层很难把某些可理解和有用东西放到开发商手里J2EE倡议者需要用他们平台做同样事记住种可能性是将XML发信提供者层放在JMS顶部后面紧接着Java命名和目录接口或者带LDAPJNDI、NIS和COS命名等等这种和标准SOAP/BizTalk供应商EBXML供应商等等结合将是种令人印象深刻语句(介绍说明) JAVA中文站社区门户f5h;o aP f:z-D-k

$[}^a;N$kb!a ]澄清和更正:
}&P!gV]*]
sF&B{M"D由于本文在2000年8月份发表有40位读者以他们关心.Net和J2EE对比想法返回给我们(见读者回信)本文作者Jim Farley筛选过这些内容同时用电子邮件回复他们因此增加以下澄清和更正
'Xb#}P ~2M}{JAVA中文站社区门户.A6Vtf dxU7dyF2o
澄清:
~uj'RE9Sw$Y.X*RJAVA中文站社区门户:j d6F2v7l1V L
C#编译特点和Java编译特点对比似乎让读者产生混淆为了更清楚点我们用另种思路方法比较:C#代码总是以自然形式运行Java代码典型地是以解析型字节代码运行；C#可整个编译成自然代码或者编译到公共语言运行时字节代码中然后在执行期间逐次编译自然代码另方面Java代码典型地以运行时解析型字节代码方式运行(据此其交叉平台能力可以增长)同时也能够以逐次编译上下文连接方式运行；也有了些Java自然代码编译器(Jove、Bullet Train、JET等) JAVA中文站社区门户G9lS9p3Cp
JAVA中文站社区门户M I2@6F-@
作为旁注(附注)微软要求遵循Java约定解析性模式在这种模式中设计用于虚拟机字节代码本身不用于自然代码优化我没有看到有力数据证明或反驳这个要求(般应针对字节代码对比自然编译语言或者特殊针对 Java对比C#) JAVA中文站社区门户0jd
uJG#RT
JAVA中文站社区门户zZ2XOq7wF7r
在回应中有几位读者指出J2EE支持XML这介绍说明了这样个事实:J2EE1.3版(现以草案方式发布)要求任何兼容J2EE产品必须包含Java XML SAX和DOM语法解析器这正是我说“把XML SAX/DOM捆绑到Java上我已经要求他们采取进步措施以J2EE支持API方式直接支持XML协同工作最理想思路方法是基于J2EE部件和服务应让XML在某种程度上自动支持内建(对发信、接口描述、输出等)
b;?T]W\OiJAVA中文站社区门户N4GA*xg0k3K
更正: JAVA中文站社区门户p"z/PI)c'@U

"v7y,m"c-N-Y我在本文中说:C#“借用了某些JavaBeans部件概念”这句话没有证据正如几位读者指出更合适说法是“微软C#功能多于它们本身COM和VB模型这是由于来自其它已有部件模型影响

TAG: NET Net Sun SUN sun 微软 对垒