.net framework for java programmers author: ashish banerjee
objective
after reading this article java programmers should be able to decipher and de-jargonize the .net architecture and relate it with the proposed ecma standard.
target audience
java programmers and system architects.
summary
this article outlines microsoft's proposed standardization of .net framework in ecma forum as cli (common language infrastructure), but the microsoft documentation refer this as clr (common language runtime). the clr and jvm are compared with respect to market forces which shaped the clr definition. components of clr are examined followed by details of microsoft's implementation of the clr as the .net framework. all along .net framework is compared with java architecture. the material is derived from author's own experience with java since early 1996, microsoft's msdn site and standard documents from sites like ecma and w3c.org.
overview
.net framework is the microsoft's answer to java commune's objections to /"windonization/" of java. microsoft introduces a new language c#, designed by the visual j++ team. but in the process it has done away with dcom and also have changed it's flagship language visual basic. in a nutshell, .net constitutes presently of three compiled languages c#, vb.net and c++, a java like runtime virtual machine environment, five execution containers hosting this runtime, namely: asp.net, windows shell, vba scripting host for office suite, visual forms container and ie (internet explorer). much like java it contains a rich set of api and lib. enhancements over java framework include use of soap (simple object access protocol) for remoting. version and security scoping using concept of application assembly (described later). a common type system is introduced for making mixed language programming easier. for example a vb component can inherit from a c# class. in longer term java and .net will converge and therefore an overview of the new framework is presented here from java programmer's perspective.
comparing clr with jvm
the .net framework's common language runtime (clr) is much similar to java virtual machine (jvm), in terms of garbage collection, security, just in time compilation (jit). however, the fundamental difference arises from the variance in perception of the sun's java design team headed by james gosling and that of microsoft's c# designers spear headed by anders hejlsberg sun viewed the internet as an heterogeneous network consisting of multiple operating systems. thus sun had to design the gui as the least common factor, supportable by all such platform. this was also the major reason of java's failure in client side applications. java has been successful only on server side where there is no great need for gui. having failed at client side desktop application arena, sun is now targeting java to server side applications market, which is dominated by unix and linux flavors having approximately 60% of the server market, the rest 40% rests with windows nt. but this view was not conducive to microsoft, which holds about 90% of client side desktop market. microsoft wanted to provide a window centric internet development platform. thus it added a few window specific features in it's java implementation, similar to what it had had done with it's c++ implementation. this along with microsoft's refusal to support java rmi, which competed with it floundering remoting technology called dcom, resulted a law suite. microsoft lost the law suite in late 2000, and had to pay usd 20 million to sun as settlement amount. this antagonist attitude made microsoft break away from java and float it's own language called c#. the c# team was carved out of the microsoft j++ team, and it's effort finally led to the creation of .net framework. microsoft intends to leverage it's desktop leadership, to shape the internet applications development by introducing the .net framework. thus the supported languages map the windows gui more closely in it's framework, much similar to c++ mfc and j++ wfc (windows foundation classes). in spite of the platform independence design claims, all the three supported languages produce windows .exe code by default. microsoft played the standardization game better than sun. microsoft, though being an usa based company proposed the c# and common language infrastructure (cli), the back bone of .net framework, for standardization with ecma (european computer manufacturing association) tc39 technical committee in october 2000. ironically sun also happens to be a member of this standing committee, which looks after computer languages related standardization issues. see http://www.ecma.ch. microsoft has also successfully standardized simple object access protocol (soap) through w3c (http://www.w3c.org). soap is a xml and http based remote object access protocol. soap competes with java's rmi and microsoft's own dcom. rmi has the limitation of being language specific, and dcom had limited acceptability outside the windows community, this was, despite the best of microsoft's effort to port dcom on unix platforms. corba, another remoting contender, which even has internet specific transport namely iiop, is more or less dead, due to it's vendor non interoperability. soap, by virtue of http transport can operate easily over firewalls and therefore can easily transident lan and internet. however, soap being xml based, burdens both client and server for xml parsing, which is relatively cpu intensive, compared to binary protocols like rmi and dcom. java platform views the internet world as one language running on different operating systems (os), whereas .net framework views the world running on one os with a programmers having choice of multiple languages. therefore java platform interpolates multiple operating systems, and .net framework interpolates multiple languages. apparently from the above discussion, the market forces are largely responsible for the state-of-the-art rather than technical design considerations.
inside the common language runtime
the common language runtime (clr), is the runtime environment of the .net framework, which manages the execution of code and provides services. the common language runtime (clr), is also proposed for ecma standard. however, the ecma documents refer the clr as common language infrastructure (cli). it has five components namely:
cts - common type system
cls - common language specification
cil - common intermediate language
jit - just in time compiler
ves - virtual execution system
cli - common language infrastructure
the common language infrastructure (cli) provides a language neutral platform for application development and deployment. cli supports both object oriented paradigm (oop) as well as hooks for modeling procedural and structured languages. cli provides languages with a framework for security, garbage collection, exception handling and also provides a platform for language interoperability. for example c# objects can inherit from c++ classes and vb procedures can use the c# components. please note that the microsoft documentations refer cli as clr (common language runtime). after reading through the ecma standard documents, like me, you will probably develop the feeling that cli is an attempt to standardize the next generation java framework for accommodating the older pre internet era languages like vb and c++. the five components of the cli is briefly described below.
cts - common type system
the common type system, support both object oriented programming like java as well as procedural languages like 'c'. it deals with two kinds of entities: objects and values. values are the familiar atomic types like integers and chars. objects are self defining entities containing both methods and variables. objects and values can be categorized into the following hierarchy: types can be of two kinds value types and reference types. value types can further categorized into built-in (for example integer types and float type) and user defined types like enum. reference type can be divided into three sub categories: self describing reference type, pointers and interfaces. pointers can be sub divided into function pointers, managed and unmanaged types. value types can be converted into reference type, and this conversion is called boxing of values. de-referencing the boxed value types from the referenced type is called un-boxing. casting rules from one type to another, for example conversion of char to integer types are also defined within the common type system. common type system also defines scope and assemblies. an assembly is a configured set of loadable code modules and other resources that together implement a unit of functionality. a scope is a collection of grouped names of different kinds of values or reference types.
