Java Forum 2001

1. Java Forum 2001 Clemens F. Vasters CTOclemensv@newtelligence.com The Common Language Runtime

2. COM – The Good Things • Commercially most successful component model in history – for component vendors • COM concepts adopted throughout the industry • Influenced many environments on many platforms • Most complete component infrastructure • From Compound Documents to Enterprise Services • Microsoft Transaction Server (1996, now COM+) • Introduced component oriented transactions • Component and role-based security • If there wasn't MTS, there would be no J2EE or OTS • J2EE steps on over 20 Microsoft MTS-related patents

3. COM – The Bad Things • Essentially "Windows Only" • Only a single port to other platforms (Software AG) • Mainsoft, Bristol, Microsoft use Software AG port • Quite limited Type-System • Only scalar types for most scenarios • Relies on binary layout of C++ • Hard to implement with languages like SmallTalk • DCOM wire-protocol is a closed model • Not extensible and hard to configure • Components must be registered • Requires local code, system easily polluted • Versioning difficult, "DLL Hell" • Registration always has global scope

4. Java – The Good Things • "Write once, run anywhere" • Single code-base runs on many platforms • Executed on an isolated virtual machine • Abstracts machine details • Great, clean programming language • Great features for server-side development • Automatic memory management • Remoting model, network support • J2EE Enterprise Java Beans

5. Java – The Bad Things • "Write once, test anywhere" • Many different JVMs, many different bug-sets • JVMs are simply no picnic to build • JVM model is in jeopardy • Applets and Java Desktop apps are essentially dead • Server-side Java quickly fractioning (IBM,BEA,Sun) • J2EE betrays the "write once" model • App-Server vendors enhance core spec • Using essential features causes vendor lock-in • Real world apps need platform integration ! • Where is Sun 's platform support for SOAP, WSDL ?!? • Real solutions run on one deployment platform

6. What Is Microsoft .NET ? XML Web Services Building Blocks"Hailstorm" YellowPages ... ... .NET Solutions Languages C#, Visual Basic, Python, Perl,... .NET Enterprise Servers IL Runtime Layer SQL Server BizTalk ... XML COM/Interop Services.NET, OS and COM+ Services Common Type System Common Language Runtime P/Invoke .NET Framework Operating System

7. Microsoft .NET is ... • The Common Language Infrastructure (CLI) • Common Type System • Common Language Runtime • Intermediate Language • CLI Class Framework (subset of .NET Framework) •  all of those are already submitted to ECMA TC39 • The Development Languages and Tools • .NET Framework SDK • with C#, VB.NET, C++, JScript.NET • C# also submitted to ECMA TC39 • Microsoft Visual Studio.NET • Web Services ("Hailstorm") • .NET Enterprise Servers

8. The Common Language Runtime • Jobs of the Common Language Runtime: • Code management, Loading and execution of managed code (IL or native) • Software memory isolation, memory management • Conversion of IL to native code (JIT invocation), Verification of the type safety of IL • Accessing metadata (enhanced type information), object layout • Insertion and execution of security checks • Handling exceptions, including cross-language exceptions • Interoperation between .NET Framework objects, platform services and COM objects • Supporting developer services (profiling, debugging)

9. Thread Support COM Marshaler Type Checker Exception Manager Security Engine Debug Engine IL to Native Compilers (JIT) Code Manager Garbage Collector (GC) CLR Diagram Base Class Library Support Class Loader

10. The Intermediate Language (IL) • Simple, object-oriented Assembly language • Stack based, no registers • Automatic, method-level storage locations • Each stack slot is System.Object typed • Supports tail calls and other multi-language necessities • Type-safe without needing typed operators • Allows "Generics" (Templates) in later CLR version • Designed to be compiled into native code • No "virtual machine" concept or restrictions • Dissolves into 100% pure machine code at runtime • Comes with standardized canonical representation • There is an actual assembler (ilasm) for IL

11. CLR Execution Model (1) SourceCode IL &Metadata LanguageCompiler Common Language Runtime Execution Engine ClassLib Class Loader JIT Compiler ManagednativeCode Execution

12. CLR Execution Model (2) • All CLS-compliant languages compile into IL • IL code is wrapped by metadata • Host process hosts CLR, loads initial metadata • CLR loader resolves external references • All code is always JITted into native code • PreJIT: JIT at installation time • EconoJIT: JIT at runtime – fast JITting • Standard JIT: JIT at runtime – balances speed/optimization • OptJIT: JIT at runtime – fast, optimized code • JITter optimized for machine (SMP,64Bit,etc.)

13. The Common Type System • A common type system for all .NET languages • Rich, seamlessly shareable types and classes • Enables cross-language (re)use • Enables cross-language inheritance • Roots in XML Schema Part-2 • Every simple and complex type is derived from System.Object • Includes simple types (int, float) • No "magic" types as in Java, C++

14. Type Characteristics • Value types • Represented by sequence of bits in a location • Common built-in data types • Boxing: • Unboxed: No associated metadata, pure data • Boxed: Full metadata, all object features • Reference types • Represented by location and sequence of bits • Objects, Interfaces, References, boxed values

15. Built-In Value Types • Integer values • int8, int16, int32, int64 • unsigned counterparts • Super long decimal value • decimal (28 digits) • IEEE Floating point values • float32, float64 • Unicode character values • char, string (immutable reference type) • Boolean value • bool

16. System.Object • Base class for each and every type • Inheritance from System.Object is typically implicit • All simple and complex types share the same base • Single base-class makes framework consistent • Collection classes can be used for everything • Intrinsic model for handling variant types • Strongly typed. No pointers, no structures. • System.Object is a reference type • Value types (internally) inherit from ValueType • Special class derived from Object • No type is "magic"

17. Memory Management • The .NET memory manager is a garbage collector • All .NET languages (including C++) are GC'ed • .NET Garbage Collector implementation: • Automatically moves objects to optimize layout • Supports "pinning" to temporarily suspend moving for certain Interop scenarios. • Implements multi-generation algorithm • Youngest objects go first, Oldest objects go last • Opt-out model for running Finalizers on shutdown

18. Application Domains • Fully isolated execution space for applications • Independent of OS concept of thread, process • CLR can be shared by multiple app domains Process Process AppDomain AppDomain AppDomain Object Object Object Object Object

19. Threading • All .NET languages are fully multi-threaded • Each .NET thread runs on an OS thread. • Each process automatically maintains a ThreadPool • Thread binds to object-bound delegate • Object-based thread entry points • Synchronization support through: • Monitor (critical sections, lightweight locks) • Mutexes • .NET Remoting Context based synchronization

20. Assemblies • Single-File or Multi-File group of code and "baggage" • An Assembly can consist of • Multiple modules (code containers) • One module can host any number of classes • Any number of auxiliary files (.jpg, .html, .anything) • Assembly "directory" is called the "Manifest" • Contains all internal and external file references • Contains information about • Versioning • Code Originator (digital signature) • External References • Security Permission Requests • …

21. Strong Name Assemblies • A "strong name" is a world-wide unique name • Achieved by digitally signing Assemblies with an X.509 PKI private/public key pair • Strong Names enable: • Seamless side-by-side installation and use of any number of versions of the same Assembly • Automatic updates through versioning algorithms • Code and "baggage" integrity through signature • Strong Name Assemblies can be shared • Installed in "Global Assembly Cache" • Versioning Scheme: Major.Minor.Revision.Build • Revisions override previous versions • Major/Minor updates require configuration

22. .NET Security • Evidence and PKI based code access security • Origin and integrity of code through signatures • No code spoofing, unauthorized patches • Rich permission-based system, configurable sandbox • Can turn off unsafe code, P/Invoke and COM/Interop • Role based and identity based user-level security • Cascaded security policy model • Configure security policies based on code origin, user groups, etc. • Enterprise, Machine, User and AppDomain level

23. .NET Security (2) • Detects unauthorized code at load-time through manifest and code inspection • Dynamic permission management at runtime through stack walks Call chain Assembly A1 G1 P Assembly A2 G2 P Assembly A3 G3 P Assembly A4 G4

24. .NET Reflection [serializable]public class Person : { public event OnSaveChange onsv; public Date DOB; public string FirstName; public string LastName; public string Name { get { return FirstName + " " + LastName; } } public void Person(string First,string Last) { FirstName=First;LastName=Last; } public bool Save() { System.Type t = this.GetType(); foreach( FieldInfo f in t.GetFields() ) { ... } } System.Type Attributes Events Fields Properties Constructors Parameters Methods

25. .NET Reflection.Emit • Full representation of physical structure • Allows building modules and assemblies at runtime • Transient code only used at runtime • Persistent code for reuse • Create classes, types and emit IL • Used by .NET compilers to build .NET apps • Scenarios • Build classes dynamically from script-like code • .NET XPath, Regular Expressions do just that ! • Create dynamic wrappers for existing code • Transfer code-chunks to remote machines • Distributed processing scenarios (like SETI@home) • Attribute-Driven Templates

26. .NET Remoting Infrastructure • Open Remoting channel architecture • Channels can talk to any arbitrary endpoint • No assumption is made about endpoint archtecture • Can be Linux, Java, Solaris, you name it • In .NET: HTTP; SMTP and raw TCP-Sockets channels • Extensible: You add APPC, MQSeries, etc. Channel Client Server "Proxy" Dis-patcher

27. .NET Remoting Infrastructure • Formatters: Turn data into wire formats • In .NET: Binary and SOAP formatters • Extensible architecture: You can supply RMI, IIOP SOAP, Binary, Custom decode from wire format Channel encode into wire format

28. .NET Remoting Contexts • Derived from COM+ context idea • Encloses objects with same functional context • Carries shared properties that describe behavior • Allows message interception and manipulation at any remoting boundary AppDomain Object Context Context remoting boundary Object Object Object Object Object Object RqTx Sync Thrd

29. Enterprise Service Integration • Transactions through COM+ Transaction integration • Uses attributed programming style • Components are automatically registered in COM+ [Transaction(TransactionOption.Required)]public class MyComponent : ServicedComponent{ // everything transactional here} • Same level of integration for all other COM+ services • .NET Framework Level support for • Message Queuing, WBEM/WMI, Directory Services, System Diagnostics, Performance Counters, etc.

30. Instantiate controls Parse .aspx file Generate page class ASP.NET Web Forms Execution Model Client Server IIS Request .aspx file ASP.NET Runtime Response

31. ASP.NET Web Forms Event Model event message Server Web Client event parse message call appropriateevent handler event handler response

32. ASP.NET is compiled, native code IIS ASP.NET runtime assembly exists, same timestamp? file exists? 1 2 3 2a run no? compile <%Page codebehind="pg"%><html><body> <asp:label/> <asp:textbox/></html></body> ASP.NET compiler Page Assembly Reflection class pg : Page{ ... }

33. Web Service Infrastructure Web Service Client(any .NET app,any SOAP client,any device) Request disco Discovery Web Service(ASP.NET, .NET Remoting) Return disco (XML) Request WSDL Description Return WSDL (XML) Request .asmx / Endpoint Protocol Return response (XML)

34. And what about Java ? JUMP! What Microsoft is delivering What this means for developers Path 1:Use the Java language on .NET • Tools • Java-to-IL translator • Binary component converter • Convert .class files to IL • Can reuse as is • Can convert to IL • Interop layer – for library support at JDK1.1.4 level • Visual Studio.NET integration • Java as a 1st class language • Financial assistance with your therapy • Options • Re-build existing VJ++ source to run on .NET CLR • Continue writing new code in Java • Can use Java.* class packages as defined by JDK 1.1.4 • Regarding existing Java .class files • Can reuse as is • Can convert to IL Path 2:Full Migration to .NET • Tools • Java-source-to-C# source translator/converter • Options • Convert existing Java modules to C# • New development in C# • Projects can reference Java classes running on the interop layer (from above)

35. Questions? ? clemensv@newtelligence.com

36. Further Information • On the Web: • www.microsoft.com/germany/msdn/ • msdn.microsoft.com • www.microsoft.com/net • Newsgroups: • microsoft.public.dotnet.* • ".NET Crashkurs"Vasters, Oellers, et. al.Microsoft Press DeutschlandISBN: 3860635131

37. learn more @ www.newtelligence.com Software • Engineering • You & Tomorrow Thank You!