G53ELC

JAVA & .NET (BC vs. IL)

G53ELC

Microsoft .NET Framework Vs. Java

The Common Language Infrastructure CLI and Microsoft .NET Framework languages like C# and VB share various similarities with Sun Microsystems’s JVM and Java.

These are virtual machine models which conceal the computer hardware details on which their programs run. The other similarity is that both of these frameworks make use of their own intermediate byte-code.

Microsoft naming theirs Common Intermediate Language and Sun naming theirs as Java bytecode.

G53ELC

Java and C#.NET

> java hello

hello.java

hello.class

javac

9E8E Java bytecode

hello.cs

hello.exe

csc

9E8E Common Intermediate Language (CIL)

> hello.exe

these run in differentvirtual machines

assembly

G53ELC

Common Intermediate Language

Common Intermediate Language formerly called MSIL is the lowest-level human-readable programming language defined by the Common Language Infrastructure (CLI) specification and is used by the .NET Framework and Mono.

Languages which target a CLI-compatible runtime environment compile to CIL, which is assembled into an object code that has a bytecode-style format.

CIL is an object-oriented assembly language, and is entirely stack-based. Its bytecode is translated into native code or executed by a virtual machine.

G53ELC

Bytecode Bytecode, also known as p-code (portable code),

is a form of instruction set designed for efficient execution by a software interpreter.

Bytecodes are compact numeric codes, constants, and references which encode the result of parsing and semantic analysis of things like type, scope, and nesting depths of program objects.

They therefore allow much better performance than direct interpretation of source code.

G53ELC

Java Byte Code and MSIL

Java byte code (or JVML) is the low-level language of the JVM.

MSIL (or CIL or IL) is the low-level language of the .NET Common Language Runtime (CLR).

Superficially, the two languages look very similar.

JVML:iload 1iload 2iaddistore 3

MSIL:ldloc.1ldloc.2addstloc.3

G53ELC

Cont..

One difference is that MSIL is designed only for JIT

compilation.

The generic add instruction would require an

interpreter to track the data type of the top of

stack element, which would be prohibitively

expensive.

G53ELC

Bytecode & MSIL contains…

Load and store

Arithmetic and logic

Type conversion

Object creation and manipulation

Operand stack management

Control transfer

Method invocation and return

G53ELC

The execution engines

The Bytecode and MSIL is interpreted by virtual

machines…

JVM for Java Bytecode

CLR for MSIL

G53ELC

Java virtual machine (JVM)

A Java virtual machine is software that is implemented on virtual and non-virtual hardware and on standard operating systems.

A JVM provides an environment in which Java bytecode can be executed, enabling such features as automated exception handling,

G53ELC

Java Run-Time System

Byte

Code

Verifier

Class

Loader

Interpreter

Just-in-time

Compiler

Java

Runtime

Hardware

G53ELC

JVM Architecture

G53ELC

A Bytecode Example

public class X {

public static voidmain(String[] args) {

add(1, 2);}

public static intadd(int a, int b) {

return a+b;}

}

public static void main(java.lang.String[]);

Code: 0: iconst_1 1: iconst_2 //Method add:(II)I

2: invokestatic #2; 5: pop 6: return

public static int add(int,int); Code: 0: iload_0 1: iload_1 2: iadd 3: ireturn

G53ELC

Common Language Runtime

CLR sits on top of OS to provide a virtual

environment for hosting managed applications

What is CLR similar to in Java?

Java Virtual Machine (JVM)

CLR loads modules containing executable and

executes their code

G53ELC

Code might be managed or unmanaged

In either case the CLR determines what to do

with it

Managed Code consists of instructions written in

a pseudo-machine language called common

intermediate language, or IL.

IL instructions are just-in-time (JIT) compiled into

native machine code at run time

G53ELC

Compiling and executing

managed code

Source Code

Language Compiler

Microsoft Intermediate

Language (MSIL)

Compilation

JIT Compiler

NativeCode

The first time each method is called

Execution

G53ELC

Common Language Runtime

G53ELC

G53ELC

Architecture

G53ELC

Programming model

Common Language Runtime Execution Engine

CIL &Metadata

ClassLib

Class Loader

ManagednativeCode

Execution

Compiler

JIT Compiler

SourceCode

G53ELC

C# Code

using System;namespace Swapping{    class Swap    {        int a, b, c;        public void Get()        {              Console.WriteLine("Enter 2 no");           this.a = Convert.ToInt32(Console.ReadLine());            this.b = Convert.ToInt32(Console.ReadLine());        }        public void Show()        {           this.c = this.a;            this.a = this.b;            this.b = this.c;            Console.WriteLine("After Swapping a={0} b={1}", this.a, this.b);        }    }}

G53ELC

G53ELC

G53ELC

G53ELC

25

CLR vs JVM

C# ManagedC/C++

Lots of otherLanguages

VB.Net

CLRCTS GC Security Runtime Services

MSIL

Windows OS

Java

JRE (JVM)GC Security Runtime Services

Byte Codes

Mac Unix LinuxWin

Both are ‘middle layers’ between an intermediate language & the underlying OS

G53ELC

26

JVM vs. CLR

JVM designed for platform independence

Single language: Java (?)

A separate JVM for each OS & device

CLR designed for language independence

Multiple languages for development

C++, VB, C#, (J#)

APL, COBOL, Eiffel, Forth, Fortran, Haskel,

SML, Mercury, Mondrian, Oberon, Pascal,

Perl, Python, RPG, Scheme, SmallScript, …

G53ELC

Impressive usage of formal methods and

programming language research during

development

Impressive extensions for generics and

support for functional languages

underway

Underlying OS: Windows (?)

G53ELC

28

JVM vs. CLR at a glance

JVM CLR

Managed execution environment

X X

Garbage Collection X X

Metadata and Byte code X X

Platform-abstraction class library

X X

Runtime-level security X X

Runs across hardware platforms

X ?

G53ELC

A typical .NET Enterprise Solution

29

SQLServer

IIS on W2k Server

.NET managed component

ASP.NET

WindowsClient

Browser

G53ELC

A typical J2EE Enterprise Solution

30

DB Server

Java App Server

EJBServletJSP

Java Client

Browser

G53ELC

Web services

Web services are typically application programming interfaces (API) or Web APIs that are accessed via Hypertext Transfer Protocol (HTTP) and executed on a remote system hosting the requested services.

An application that exists in a distributed environment, such as the Internet.

A Web service accepts a request, performs its function based on the request, and returns a response.

G53ELC

Advantages of Web service

Not based on a programming language:Java, .Net, C, C++, Python, Perl, …

Not based on a programming data model:objects vs non-objects environments.

Based on web technologies

Do not need huge framework of memory.

Basic usage is b-to-b ,remote controlled devices ,etc.

G53ELC

Web services application

Can use Web Services to integrate across departments, agencies, to companies, etc.

G53ELC

Web service Architecture

An architecture view based on SOAP, WSDL, and UDDI.

G53ELC

WS built on existing standards

Extensible Markup Language (XML) The HTTP (Hypertext Transfer Protocol) standard

is allowing more systems to communicate with one another.

SOAP (Simple Object Access Protocol) (built on XML) standardizes the messaging capability on different systems.

UDDI (Universal Description,Discovery, and Integration ) standardizes the publishing and finding of Web services.

WSDL (Web Services Description Language ) standardizes the description of Web services so providers and requesters are speaking the same language.

G53ELC

Web Services technology

3 major Web services toolkits being used widely, .NET Web services: Developed by Microsoft and

is an integral part of the complete .NET framework. Integrated and easy to use with Visual Studio .NET. services are hosted on IIS web servers.

Java Web services: Sun’s Web service implementation for the Java community. Comes bundled in a complete Java Web services Development Pack (JWSDP Ver 1.3) including Tomcat web server.

 Apache Axis: Initially developed by IBM and donated to the Apache group. One of the earliest and stable Web service implementation. Runs on Apache Web servers.

G53ELC

A Web Service example in Java

SOAP-awareServlet

(e.g. Apache Axis)

SOAP-awareServlet

(e.g. Apache Axis)

Any classprocessing

the incomingrequests

(“business logic”

Any classprocessing

the incomingrequests

(“business logic”

Any classprocessing

the incomingrequests

(“business logic”

Any classprocessing

the incomingrequests

(“business logic”

Any classprocessing

the incomingrequests

(“business logic”

Any classprocessing

the incomingrequests

(“business logic”

Any classprocessing

the incomingrequests

(“business logic”

Any classprocessing

the incomingrequests

(“business logic”

HTTP Server

Servlet engine (e.g. Apache Tomcat)

Sending requests,

getting results

Sending requests,

getting results

G53ELC

Usual principles of Java toolkits

Writing server is easier than writing clients (but only regarding the toolkit, not the business logic)

Servers may be written independently on the used toolkit

Always test interoperability with a non-Java client (because of data serialization and de-serialization)

Steps: write your service implementation make all your classes available to the toolkit deploy your service (usually done just once) restart the whole servlet engine test it with a client request

G53ELCpackage hello;public interface HelloWorld {

String getHelloMessage();void setHelloMessage (String newHello);

}

package hello;public class HelloWorldService

implements HelloWorld {String message = "Hello, world!";public String getHelloMessage() {

return message;}public void setHelloMessage (String newMessage) {

message = newMessage;}

}

hello/HelloWorld.java

hello/HelloWorldService.java

G53ELC

import org.apache.axis.client.*;public class HelloWorldClient { public static void main (String [] args) { try { // prepare the call (the same for all called methods) Call call = (Call) new Service().createCall(); call.setTargetEndpointAddress (new java.net.URL("http://localhost:8080/axis/services/Hello"));

// call "get message" if (args.length == 0) { call.setOperationName ("getHelloMessage"); String result = (String) call.invoke ( new Object [] {} ); System.out.println (result); System.exit (0); }

// call "set message" and afterwards "get message" call.setMaintainSession (true); // TRY also without this line... call.setOperationName ("setHelloMessage"); call.invoke ( new Object [] { args[0] } ); call.setOperationName ("getHelloMessage"); System.out.println (call.invoke ( new Object [] {} ));

} catch (Exception e) { System.err.println ("ERROR:\n" + e.toString()); } }}

HelloWorldClient.java

G53ELC

Generated for HelloWorld

HelloWorldServiceLocator

implements

HelloWorldService

HelloSoapBindingStub

implements

HelloWorld

getHello()

1. Make an instance of this

3. Call methods on this proxy object

2. Use it to make an instance of this

G53ELCpublic class HelloWorldClientFromStubs { public static void main (String [] args) { try { // prepare the calls (the same for all called methods) hello.generated.HelloWorldService service = new hello.generated.HelloWorldServiceLocator(); hello.generated.HelloWorld myHelloProxy = service.getHello();

// call "get message" if (args.length == 0) { String result = myHelloProxy.getHelloMessage() System.out.println (result); System.exit (0); }

// call "set message" and afterwards "get message” myHelloProxy.setHelloMessage (args[0]); System.out.println (myHelloProxy.getHelloMessage());

} catch (Exception e) { System.err.println ("ERROR:\n" + e.toString()); } }}

HelloWorldClientFromStubs.java

G53ELC

43

Java vs .Net Solutions

Both multi-tiered, similar computing technologies

Both support “standards”

Both offer different tools & ways to achieve the

same goal.

A lot of parallelism can be seen.

G53ELC

Java .Net

G53ELC

.NET vs. Java: standard libraries

.NET Framework class library Defined by Microsoft Somewhat Windows-oriented Organized into a hierarchy of namespaces

J2SE, J2EE Defined by Sun and the Java Community

Process Not bound to any operating system Defined as packages and interfaces

G53ELC

Class Libraries

G53ELC

47

The TMC Petshop Performance Case Study

Java Pet Store is Sun’s primary blueprint

application for J2EE

Source: http://java.sun.com/j2ee/blueprints

Illustrates best coding practices for J2EE

Ships as a sample application in IBM

Websphere, Oracle Application Server 9i, Sun

iPlanet, and

BEA WebLogic

G53ELC

The .NET Petshop is a port of the J2EE Java Pet Store to .NET Source: http://www.gotdotnet.com/compare Implements the same functionality as Java

Pet Store Illustrates best coding practices for .NET

Framework

In the TMC Petshop Performance Case Study, The Middleware Company implemented both the Java Pet Store and the .Net Petshop. The J2EE version ran on two different

application servers All versions used the same hardware and OS

G53ELC

49

Java Pet Store Components

The Storefront presents the main user interface in a Web front-end. Customers use the Storefront to place orders for pets.

The Order Processing Center (OPC) receives orders from the Storefront.

The Supplier fulfills orders from the OPC from inventory and invoices the OPC.

The Admin presents the administrator interface in a JFC/Swing front-end. Administrators use the Admin to examine pending orders and approve or deny them.

G53ELC

50

Java Pet Store vs. .Net Pet Shop

G53ELC

51

14000

7500

9000

5000

2500

15500

11500Java Pet Store

Lines of Code Required

User Interface

4,410

Data TierMiddle Tier

2,865

.NET Petshop

14,273

5,891

ConfigurationTotal Lines of Code

710

5,404

761 412 74

2,566

Porting Java Pet Store to .NET

G53ELC

52

TMC Pages per Second

G53ELC

53

TMC Max Supported Users

G53ELC

G53ELC

A Comparison .NET or J2EE?

Which is best? In what way? For what purpose? Performance Cost Developer time

G53ELC

Standard Library

Application Platforms Today

GUI Services

Transaction Services

Web Scripting

Data Access

More

Operating System

Runtime Environment

BrowserApps

Web ServicesApps

OtherApps

LocalApps

G53ELC

.NET Framework Class Library

The .NET Framework

Windows Forms

Enterprise Services

ASP.NET ADO.NET More

Windows

Common Language Runtime

BrowserApps

Web ServicesApps

OtherApps

LocalApps

G53ELC

Standard Java Packages

The Competition- The Java Environment

Swing Enterprise JavaBeans

JavaServer Pages

JDBC More

Windows, Solaris, Linux, others

Java Virtual Machine (VM)

BrowserApps

Web ServicesApps

OtherApps

LocalApps

G53ELC

But!

.NET IS COMPELLING! It has everything an enterprise

architecture needs It is fast It is simpler to use than J2EE to develop It has features that J2EE does not –

eg web forms It is ahead of the game in my opinion

G53ELC

.Net Needs Less Code

G53ELC

Runtime Statistics

.NET ran 28 times faster that J2EE Supported 7.6 times more concurrent

users Used ¼ the CPU cycles for the same load Do not believe these statistics!

Picked to show MS in best possible light But it .NET is probably more efficient

G53ELC

Reference

Unix Internal- Urash Vahalia Operating Systems-William Stallings

G53ELC

THANK YOU

63