正確的響應是甚麼？

對于微軟的開發商，.Net是一個好的構架，你可以將許多事情交給微軟的體系結構去完成。asp.net比ASP好，ADO.NET比ADO和DCOM出色，但有所差別，C# 比C和C++更好。.Net最初版將在2001年的某個時候可以得到，因此你有足夠的時間預備。但是可以肯定，它將成為微軟平臺的缺?。s定）開發環境。假如您現在正在微軟的開發構架中從事開發工作，將.Net的元件采納到你的體系結構中，肯定能夠獲得利益。

但是，.Net平臺的幾個期望目標極高，但不能保證全部起步，至少在短期內完成不了。例如IL公共語言運行時在使開發者獲益之前還有某些明顯的障礙需要克服。想要把每一種語言和元件運行時集成起來，必須定義這種語言的子集/超集，并清楚地影射到IL運行時上，和必須定義結構，以便提供IL需要的元數據，然后和必須開發適用于兩種編譯語言結構（對象、部件等）的編譯器（從xml到IL和從IL到XML），集成到IL部件字節代碼中，同時還要生成對現有IL元件的語言專用接口。

這里還有一些歷史的因由，必須開發非java語言到JavaVM的眾多橋梁，如：Jpython、PERCobol、The Tcl/Java PRoject。同時，假如有足夠的愛好，幾年前就應將Bertrand Meyes和一些別的Eiffel folk一起放到Eiffel-to-Java VM系統中(幾年后)，只有Jpython 例外。這些工具得到廣泛的采納，甚至在他們自己相關的委員會里也是這樣，即使它們似乎能夠提供一種方法，用你所偏愛的語言，為Java環境寫代碼(雖然不是整個J2EE構架)。然而為什么還這樣缺乏熱情？因為人們猶豫，不想承受從它們的開發語言中，將額外的翻譯工作加到目標構架上。假如Java環境是目標，人們通常會選擇學習Java。我預計，對.Net也是同樣正確的。人們將會選擇學習C#和用這種語言寫.Net的部件。

另一點要注重：基于.Net的SOAP將用于分布式通信，謹防性能損失。SOAP基本上意味著在HTTP上的XML。HTTP不是一個高性能的數據協議，因此XML隱含一個XML語法解析層，也就是需要更多的計算開銷。兩者相結合會大大減少相對另一種發信/通信信道的事務處理速率。XML是一種非常豐富的、十分強大的發信用的元語言。HTTP是非常靈活可移動的，因此可以防止許多防火墻的損失，但是假如事務處理速率對你是優先考慮的話，請保持你的選項打開。

 對于Java和開放資源委員會

請不要把.Net作為微軟市場競爭的手段，繼續以你們喜愛的方式理解.Net可能更輕易接受。但是.Net并不是一種精巧的標志，而是微軟策略的重大轉移，將為其平臺帶來福音。他們正在為使其它的構架和平臺在治理級上做得更好而奮斗。提供關于自身成本和無縫集成方面有用的可查詢的統計資料?，F在他們正努力把Java和開放資源自身所特有的元語言，逐步開放，然后力圖直接滿足開發商的需要。在過去一段時間里，由于他們沒有做好，兩件事情失敗了。假如你認為自己是Java和無資源平臺的福音的傳播者，那么，競爭的性質就會改變。

另外，微軟的IL運行時，至少可能有一個值得注重的目標：就是清除編程語言進入結構框架的障礙。Java清除了平臺的障礙(當然在有限范圍內，例如你不能沒有硬件資源來制作軟件)。但是為了用J2EE來作開發工作，你必須在Java環境下工作。而.Net是想讓你使用你選擇的語言來建造.Net應用程序，這是十分美妙的。盡管還有一些大問題沒有解決。如：.Net中的IL方式什么時候和是否會實際上變成廣泛使用的(工具)(如上所述)。不管怎樣，這就表明了單語言的J2EE方式存在弱點。這個弱點的重要性可以懷疑，但是它依然存在，因此它值得Java委員會考慮。假如開發商真的認為是這樣，那么就可以把力量放在Java字節代碼生成器方面，以適應非Java語言，當然這需要組織和濃縮(匯總)。

再深入研究一下J2EE，立即可以得到一些結論。為了支撐該平臺和.Net相較量的優勢。首先XML支持要無縫地集成到結構框架中，我們且不說將XML SAX/DOM語法解析器作為一組標準服務或者在配置元件中，擴展XML的使用。這里需要XML的發信和操作處于隨時可用狀態。公認的做法是在JMS頂端用XML的內容發信，但是并不是所有的平臺都有這種設施，XML空間是一堆雜亂無章的標準，非要害因素標準，API和DTD是你處理元語言時期望的。

但是微軟已經將SOAP放在基礎層，很難把某些可理解和有用的東西放到開發商手里。J2EE的倡議者需要用他們的平臺做同樣的事。記住一種可能性是將XML發信提供者層放在JMS的頂部。后面緊接著Java命名和目錄接口或者帶LDAP的JNDI、NIS和COS命名等等。這種和標準SOAP/BizTalk供給商，EBXML供給商等等的結合將是種令人印象深刻的語句(說明)。

 澄清和更正：

由于本文在2000年8月份發表的，有40位讀者以他們關心.Net和J2EE對比的想法返回給我們(見讀者回信)，本文作者Jim Farley篩選過這些內容，同時用電子郵件回復他們，因此增加以下的澄清和更正。

 澄清：

C#的編譯特點和Java的編譯特點對比似乎讓讀者產生混淆，為了更清楚一點，我們用另一種方法比較：C#代碼總是以自然的形式運行。Java代碼典型地是以解析型字節代碼運行；C#可整個編譯成自然代碼，或者編譯到公共語言運行時字節代碼中，然后在執行期間逐次編譯自然代碼。另一方面，Java代碼典型地以運行時解析型字節代碼方式運行(據此，其交叉平臺能力可以增長)。同時也能夠以逐次編譯上下文連接方式運行；也有了一些Java自然代碼編譯器(Jove、Bullet Train、JET等)。

作為旁注(附注)，微軟要求遵循Java的約定解析性模式在這種模式中，設計用于虛擬機的字節代碼，本身不用于自然代碼優化，我沒有看到有力的數據證實或反駁這個要求，(一般的應針對字節代碼對比自然編譯語言，或者非凡針對 Java對比C#)。

在回應中，有幾位讀者指出J2EE支持XML，這說明了這樣一個事實：J2EE1.3版(現以草案方式發布)要求任何兼容J2EE的產品，必須包含Java XML SAX和DOM語法解析器。這正是我說的“把XML SAX/DOM捆綁到Java上。我已經要求他們采取進一步措施，以J2EE支持API方式直接支持XML協同工作。最理想的方法是基于J2EE的部件和服務，應讓XML在某種程度上自動支持內建(對發信、接口描述、輸出等)。

 更正：

我在本文中說：C#“借用了某些JavaBeans的部件概念”。這句話沒有證據，正如幾位讀者指出，更合適的說法是“微軟C#的功能多于它們本身的COM和VB模型，這是由于來自其它已有的部件模型的影響".