Linked by Thom Holwerda on Wed 3rd Oct 2007 19:39 UTC, submitted by gonzo
.NET (dotGNU too) "One of the things my team has been working to enable has been the ability for .NET developers to download and browse the source code of the .NET Framework libraries, and to easily enable debugging support in them. Today I'm excited to announce that we'll be providing this with the .NET 3.5 and VS 2008 release later this year. We'll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries, ASP.NET, Windows Forms, ADO.NET, XML, and WPF. We'll then be adding more libraries in the months ahead (including WCF, Workflow, and LINQ). The source code will be released under the Microsoft Reference License."
Thread beginning with comment 277235
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: holly...
by TemporalBeing on Tue 9th Oct 2007 18:09 UTC in reply to "RE[5]: holly..."
TemporalBeing
Member since:
2007-08-22

I'm not seeing how you get this idea. The .NET class library is tied to Windows, but there is more effort involved in porting the VM runtime between x86, x64, and IA-64 than to other OSes. The VM also runs on ARM.

However - all of those are still being written to Windows and the Windows APIs. Where as Java is being written to multiple APIs (POSIX, Windows API, etc.). This can make a big difference in how it performs and the optimizations in the code structure. For example - Signaling (SEH vs. Posix Signals), Error Handling, Threading, Multi-process, Memory models, etc. All of these things change between OS's, even if in only minor details.

Cross Platform is more than just processor architecture - it is also the Operating System.

Reply Parent Score: 1

RE[7]: holly...
by PlatformAgnostic on Tue 9th Oct 2007 22:09 in reply to "RE[6]: holly..."
PlatformAgnostic Member since:
2006-01-02

Memory models do not change between OSes, AFAIK (I could stand to be corrected if I'm wrong). They're a facet of the underlying hardware platform. The underlying API might affect the performance of the class library, but the classes that are performance critical are rewritten for each platform anyway, so Java probably uses the exact same mechanisms as .NET on Windows.

As I understand it, Java was designed to be interpreted as well as compiled, while .NET was optimized purely for compilation before execution (and the CLR today doesn't ever interpret code, AFAIK). The underlying OS shouldn't make that much of a difference here... and the VMs can be optimized for the target platform anyway. There's nothing particularly tied into Windows in .NET. In fact, the CLR can be hosted in SQL server which redefines many of the OS primitives to work better for database transactions. In the SQL scenario, .NET does not call directly down into the OS for most important tasks. Instead it calls SQLOS: http://blogs.msdn.com/slavao/articles/441058.aspx.

I have to be honest, though... I do not know if .NET is faster than Java or how much. It may or may not be, but I haven't done any benchmarking myself, so I'd be hard-pressed to say anything. I'm just trying to argue against your premise that the underlying platform has much of an effect on the speed of executing the Managed Code. I also don't think a little bit of incremental speed each way makes much of a difference. One would be expected to pick .NET or Java for other reasons than a 10% performance advantage either way. .NET would be chosen for its language independence and Windows support, while Java would be chosen for its maturity and comparative ease of moving applications from one OS to the other (though anyone seriously doing this would need to do significant testing to make sure things really are the same).

Reply Parent Score: 2