Java and .NET

I l @ ve RuBoard

Java was developed as a language that could run anywhere , on anything. Java's portability has both solved and caused problems. The language itself is neat, but some of the "bolt-ons" that have emerged since the language first emerged have not been quite so effective.

The Java language was designed to let developers write generic software. Java runs using a Java Virtual Machine (JVM), which is usually a piece of software that executes Java bytecodes. Bytecodes are the low-level instructions that the Java compiler converts Java source code into ”they are the "machine code" of the JVM. Java applications run on any compliant JVM, regardless of the underlying operating system, without ever needing to be recompiled.

The problem is that different operating systems provide different facilities, so the Java language and the JVM occasionally have to take responsibility for implementing what could be considered operating system “level features. Take events, for example. Some operating systems have built-in support for events, but others do not. A JVM has to emulate events on operating systems that provide no intrinsic support. This is OK. But when the operating system does supply events, Java applications must still go through the JVM to use them, and this adds an extra level of indirection, which is bound to impair performance. If you require direct access to the underlying operating system, or to non-Java code, you can use the Java Native Interface (JNI). But be prepared to spend time debugging your code ”the JNI is not the most friendly of environments.

To build enterprise applications in Java, you need to use Java 2.0 Enterprise Edition (J2EE). J2EE is simply a specification of the infrastructure required to build enterprise applications. It includes elements such as Enterprise JavaBeans (EJB) for building shared business components , the Java Naming and Directory Interface (JNDI) for locating various Java services, the Java Transaction Service (JTS) for managing distributed transactions, JavaServer Pages (JSP) and Servlets for creating dynamic Web applications, and the Java Messaging Service (JMS) for using message queues. To build and deploy an enterprise application using J2EE, you must obtain a separate J2EE server that implements these features. The J2EE server effectively runs as an application on top of the operating system, and your Java code runs inside the environment created by the J2EE server.

Microsoft has recognized the strengths and weaknesses of Java and J2EE, and with J# and .NET it offers a solution ideally suited to the Windows platform. J# uses the syntax and semantics of the Java programming language while integrating with .NET to provide the enterprise infrastructure. You don't need to purchase a J2EE server because everything you need is built into Windows and .NET. Much existing Java code (not J2EE) will run unchanged under .NET. Where there are weaknesses in the JVM, Microsoft has replaced them with its own Windows-specific features. (For example, RMI has been supplanted by .NET Remoting.)

I l @ ve RuBoard