Java vs .net

G53ELC JAVA & .NET (BC vs. IL)

Microsoft .NET Framework Vs. Java G53ELC  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.

Java and C#.NET G53ELC hello.java hello.cs javac csc hello.class hello.exe 9E8E 9E8E Java bytecode Common Intermediate Language (CIL) > java hello > hello.exe assembly these run in different virtual machines

Common Intermediate Language G53ELC  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.

Bytecode G53ELC  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.

Java Byte Code and MSIL  Java byte code (or JVML) is the low-level languageG53ELC 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. MSIL: JVML: iload 1 ldloc.1 iload 2 ldloc.2 iadd add istore 3 stloc.3

Cont.. G53ELC  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.

Bytecode & MSIL contains… G53ELC  Load and store  Arithmetic and logic  Type conversion  Object creation and manipulation  Operand stack management  Control transfer  Method invocation and return

The execution engines G53ELC  The Bytecode and MSIL is interpreted by virtual machines…  JVM for Java Bytecode  CLR for MSIL

Java virtual machine (JVM) G53ELC  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,

Java Run-Time System G53ELC Just-in- time Compiler Byte Class Hardware Code Loader Verifier Java Interpreter Runtime

A Bytecode Example public class X { public static void G53ELC main(java.lang.String[]); public static void Code: main(String[] args) { 0: iconst_1 add(1, 2); 1: iconst_2 } //Method add:(II)I 2: invokestatic #2; 5: pop public static int 6: return add(int a, int b) { return a+b; public static int add(int,int); } Code: } 0: iload_0 1: iload_1 2: iadd 3: ireturn

Common Language Runtime G53ELC  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

Compiling and executing managed code G53ELC Compilation Microsoft Source Language Intermediate Code Compiler Language (MSIL) The first time each method is called Native JIT Code Compiler Execution

Common Language Runtime G53ELC

Programming model G53ELC CIL & Source Compiler Metadata Code Common Language Runtime Class Class Loader Execution Engine Lib JIT Compiler Managed Execution native Code

C# Code  using System; G53ELC 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); } } }

CLR vs JVM G53ELC VB Managed Lots of other C# .Net C/C++ Languages Java MSIL Byte Codes CLR JRE (JVM) CTS GC Security GC Security Runtime Services Runtime Services Windows OS Mac Win Unix Linux Both are „middle layers‟ between an intermediate language & the underlying OS 25

JVM vs. CLR  JVM designed for platform independence G53ELC  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, … 26

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 (?)

JVM vs. CLR at a glance G53ELC JVM CLR Managed execution X X environment Garbage Collection X X Metadata and Byte code X X Platform-abstraction class X X library Runtime-level security X X Runs across hardware X ? platforms 28

A typical .NET Enterprise Solution G53ELC IIS on W2k Server Browser .NET SQL ASP managed Server .NET component Windows Client 29

A typical J2EE Enterprise Solution G53ELC Java App Server DB Browser Servlet Server EJB JSP Java Client 30

Web services G53ELC  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.

Advantages of Web service G53ELC  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.

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

Web service Architecture G53ELC An architecture view based on SOAP, WSDL, and UDDI.

WS built on existing standards G53ELC  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.

Web Services technology 3 major Web services toolkits being used widely, G53ELC  .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.

A Web Service example in Java G53ELC HTTP Server Servlet engine (e.g. Apache Tomcat) Any class Any class processing Any class processing Any class the incoming processing the incoming processing SOAP-aware Sending requests the incoming requests requests, (“businessincoming the logic” requests Servlet (“business logic” requests (e.g. Apache Axis) getting (“business logic” (“business logic” results

Usual principles of Java toolkits  Writing server is easier than writing clients (butG53ELC 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

hello/HelloWorld.java package hello; G53ELC public interface HelloWorld { String getHelloMessage(); void setHelloMessage (String newHello); } hello/HelloWorldService.java package hello; public class HelloWorldService implements HelloWorld { String message = "Hello, world!"; public String getHelloMessage() { return message; } public void setHelloMessage (String newMessage) { message = newMessage; } }

import org.apache.axis.client.*; HelloWorldClient.java public class HelloWorldClient { public static void main (String [] args) { try { G53ELC // 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()); } }

Generated for HelloWorld 1. Make an instance of this G53ELC HelloWorldService implements 2. Use it to make an instance of this HelloWorldServiceLocator getHello() HelloWorld 3. Call methods on this proxy object implements HelloSoapBindingStub

HelloWorldClientFromStubs.java public class HelloWorldClientFromStubs { G53ELC 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()); } } }

Java vs .Net Solutions G53ELC  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. 43

.NET vs. Java: standard libraries G53ELC  .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

The TMC Petshop Performance Case Study G53ELC  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 47

 The .NET Petshop is a port of the J2EE Java Pet Store to G53ELC .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

Java Pet Store Components  The Storefront presents the main user interfaceG53ELC 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. 49

Java Pet Store vs. .Net Pet Shop G53ELC 50

Porting Java Pet Store to .NET 15500 14,273 Lines of Code Required G53ELC 14000 .NET Petshop 11500 Java Pet Store 9000 7500 5,891 5,404 4,410 5000 2,865 2,566 2500 710 761 412 74 Total Lines User Middle Tier Data Tier Configuration of Code Interface 51

TMC Pages per Second G53ELC 52

TMC Max Supported Users G53ELC 53

A Comparison .NET or J2EE? G53ELC  Which is best?  In what way?  For what purpose?  Performance  Cost  Developer time

Application Platforms Today G53ELC Browser Web Services Local Other Apps Apps Apps Apps GUI Transaction Web Data More Services Services Scripting Access Standard Library Runtime Environment Operating System

The .NET Framework G53ELC Browser Web Services Local Other Apps Apps Apps Apps Windows Enterprise ASP.NET ADO.NET More Forms Services .NET Framework Class Library Common Language Runtime Windows

The Competition- The Java Environment G53ELC Browser Web Services Local Other Apps Apps Apps Apps Swing Enterprise JavaServer JDBC More JavaBeans Pages Standard Java Packages Java Virtual Machine (VM) Windows, Solaris, Linux, others

But!  .NET IS COMPELLING! G53ELC  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

Runtime Statistics G53ELC  .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

Reference G53ELC  Unix Internal- Urash Vahalia  Operating Systems-William Stallings

Java vs .net

More Related Content

What's hot

Viewers also liked

Similar to Java vs .net

More from Tech_MX

Recently uploaded

Java vs .net