Java / J2EE and .NET Talk

Similarities and Differences

in the Dominant Enterprise

Computing Platforms

Kyle Cordes

Oasis Digital Solutions Inc.

Gateway Java User Group

Sep. 2, 2003

Kyle Cordes

* Developer / “Architect”

* Consultant and Trainer

* Proponent of agile, iterative, test-intensive development

* Java, EJB, Oracle, SQL Server, Delphi, C++, Python,
Ruby, EJB, XML, multi-tier, etc.

* kylecordes.com

* Oasis Digital Solutions Inc.

y Outsourced development and other services

Disclosures – I Like all of the following:

* Java

* .NET

* Choice of deployment platforms

* Great development tools

* Value for the customer / user

Quick Poll – How many of you:

* Use Java at work?

* Use .NET at work?

* Use a non-Java language on the JVM?

* Deploy to Windows servers?

* Deploy to Unix servers? Solaris? AIX? HPUX?

* Deploy to Linux servers?

* Use a non-Sun JVM, from IBM, HP, etc.?

Agenda

* Overview

* Technical Similarities and Differences

* Non-Technical Issues

* Q&A

What is Java? What is J2EE?

* Platform (Infrastructure under your app)

* Managed runtime environment

* Marketing term for a diverse set of technology

* Spec and Product (from Sun and many others)

* Market

* J2EE is the name of the “high-end” features, specs,
libraries, etc.

What is .NET?

* Platform (Infrastructure under your app)

* Managed runtime environment

* Marketing term for a diverse set of technology

* Product (from Microsoft)

* Spec (though less so)

* Market (though less so)

* There isn’t an overriding brand name for the enterprise
features, some of them are WSE

What Else is .NET?

* Marketing term extends beyond the platform:

y .NET My Services

y Software as a Service

y Synonym for “new”, like “NT”

* Most of this is going away, Microsoft is removing
the .NET brand name from the next version of many products, as already happened
with Windows Server 2003.

The Essence of .NET

* Platform for building applications – like an OS

* Much like Java at both macro and micro level

* Microsoft’s alternative vision for what a Java-like
system should look like – “the same, but different”

* The Future of the Windows platform

.NET from a Java Perspective

* Start with most of the best aspects of the Java
platform (both features and texture)

* Same overall idea, different names and many
different design decisions

* Improve on some areas, with various twists

* Puts some things in platform / languages which are
conventions or add-ons in Java.

Platforms

* Java tends to make platform irrelevant

* .NET integrates with and boosts the value of the
Windows platform (*)

* (I’ll mention Mono later)

Technical Similarities and Differences

Runtime Environment

* Both provide a managed runtime environment:

y Intermediate Language / bytecode, not native
code

y Garbage collection

y Security

* Java JRE offers JIT and Hotspot

* .NET CLR offer JIT and ngen

* Common misconception among .NET partisans is that
Java is interpreted

Virtual Machine vs. Runtime

* I’ve seen the idea put forth that a “runtime” is
greatly different from a virtual machine.

* Technically speaking, not much difference

Languages

* Java Platform:

* Java language

* (and many others, though not widely used)

* .NET Platform:

* C#

* Visual Basic.NET

* C++ with Managed Extensions

* (and many others, more likely to see wide
use)

Major C# / Java Language Differences

* Properties

* Attributes

* Events / Delegates

* Value Type (Structs)

* unsigned types

* Auto-boxing

* explicit interface implementation

* Non-virtual methods by default (like Delphi)

* Override keyword

* Different method lookup rules

* foreach

* multi-dimensional arrays

* using

C# Unsafe Code

* Java:

y Write your unsafe code in C / C++ / etc.

y Call it with JNI – VM checks security

* C#:

y Use the same language

y Mark it as unsafe

y Runtime checks security

* Given that some operations require unsafe code,
writing it in the same language seems like a better solution to me.

Libraries

* Java class libraries

y java.io

y javax.sql

* .NET BCL Base Class Library

y System.IO

y System.XML

y …

* Roughly comparable in scope

Naming Conventions

* Most of .NET naming/casing conventions are different
from Java’s

y MethodName vs methodName

y Package.Name vs package.name

* Different just to be different, in my opinion

* Many more things are cased LikeThis, so the casing
carries slightly less information

* Microsoft no longer recommends Hungarian

DBMS Connectivity

* JDBC

* JDO

* SQL/J

* JDBC Type 4

* ADO.NET

* ODBC

* OLE-DB, which also supports nonrelational
data sources

* .NET Managed Provider

Deployment

* Java:

y Class files / Jars

* .NET:

y Assemblies

* J2EE: Choose and install J2EE server, generate and
compile EJB stubs, set a bunch of XML files right, create nested JARs, EARs,
etc.

* .NET: Copy assemblies and a few config files to
a directory served by IIS

JARs, EXEs and DLLs

* .NET Assemblies are substantially similar to JARs,
but they have extra header information to make them valid Win32 EXEs or DLLs

* The header includes a stub to connect to the .NET
Runtime

* Result: to the end user, .NET applications have
the same kinds of files as native.

* Big advantage in user acceptance

Classpath

* Commonly complained about by Java detractors

* .NET has a similar mechanism: load from the same
directory, load from a global location (GAC), load from configured locations
(much like a classpath)

* .NET does not have classes as standalone files,
which simplifies things.

Versioning

* .NET Assemblies carry metadata with version information

* .NET Assemblies reference each other by version

* Side-by-side deployment is easy, without the need
to segregate Jar files

* Version interop issues are similar – it’s possible
to load class Foo version 1.5 and class Foo version 2.0, but they aren’t the
same class.

Web Presentation Toolkits

* Java:

* JSP/Servlets

* Tab libraries

* JSF

* Third party toolkits (Struts etc.)

* Some toolkits provide server-side OnClick
just like the .NET

* .NET:

* ASP.NET

* Server-side controls

y Server-side OnClick

* Less emphasis on MVC

Rich Client Presentation Toolkits

* Java:

* AWT

* Swing

* “Lightweight”

* Layout management, the bane and the glory
of Swing development

* SWT and other alternatives available

* .NET:

* WinForms

* “Heavyweight” = Native

* Less focus on automatic layout, most layouts
are pixel-based

* An SWT clone is available

* WinForms is “1.0” and it shows

XML Support

* Java: JAXP and other APIs, implementations from
many vendors

* .NET: Built-in (System.XML, also including interesting
pull-model parsing)

x Built-in Schema, Xpath, XSLT, SOAP 1.1

* .NET uses XML itself extensively, while Java uses
lots of Properties files for older configurations; this is an artifact of the
timing.

Distributed Computing

* J2EE: RMI, CORBA, SOAP

* .NET: Remoting, SOAP, DCOM

* There are third party .NET COBRA implementations.

* There are third party Java DCOM bridges

RPCs / Distributed Objects

* RMI:

* JRMP or IIOP wire protocol

* RMI Registry

* Stubs/Skeleton

* Can customize with Socket Factory

* Distributed Garbage Collection!

* .Net Remoting:

* XML or native wire protocol, over HTTP/TCP

* Activator

* Can customize with Channels

* Distributed Garbage Collection!

Web Services

* RPCs, Metadata, Discovery, Directories

* SOAP, WSDL, UDDI, etc.

* .NET:

y SOAP and WSDL in the box from Day One

y More coming in the “WSE”

* Java:

y Some support in the box

y many strong solutions from 3rd parties

y Much more in the box coming soon

[WebMethod]

* Extensively hyped, great for demos

* Not an important difference in a large app

* Provided by several Java WS implementations, I was
using one before .NET existed

* Ludicrous to hold the fact against Java, that Java
predates web services

* Upcoming versions of Java and .NET will offer very
similar WS support

Clustering

* J2EE:

y Clustering provided by App Server

y Sessions maintained by the App Server

y Platform provides the spec

* Net:

y Clustering provided by OS

y Sessions maintained by IIS/OS/runtime

y Platform (Windows Server) provides the implementation

Implementing Complex Services

* Service Oriented Architectures are now the dominant
paradigm

y Client app doesn’t know whether server uses
domain objects

* Stateless services

* see Patterns of Enterprise Application Architecture,
Fowler

The J2EE Approach

* Stateless Session Beans for the Service Facade

* Entity Beans for persistance

* Many variations and recommendations out there

The .NET Approach

* Web Services or Remoting for the Service Facade

* O/R mapping is not in the box

* Instead, very convenient and powerful data access
components are used

* Thus, Transaction Scripting favored over Domain
Objects

* Of course, many developers use O/R mapping and domain-object-based
development.

Message Oriented Middleware

* Java:

y JMS and MDB specification

* .NET:

y Easy access to Microsoft Message Queue

y COM+ Queued Components (similar to MDBs)

Small Device Support

* Java offers J2ME

y Many third party variations also!

* J2ME is Java with many features removed

* Run on many cell phones, Palm devices, etc.

* Much greater market penetration so far

* .NET offers the Compact Framework

* .NET CF is the .NET Framework with many features
removed

* Runs on Pocket PC, SmartPhones, various embedded
devices

In Java / J2EE, not in .Net

* O/R Mapping, in the form of Entity Beans

* Wider array of utility APIs

* Public profiling and debugging APIs like JVMPI,
JPDA

In .Net, not in Java / J2EE

* ASP.NET Server side controls

* XML Serialization

* Precompilation to native code

* Enumerations, Attributes, etc.

Java / .NET Interoperability

* Easy to call back and forth with Web Services

y Appropriate only for large-grained EAI interaction

* Much Faster to call back and forth with CORBA

* Fast but inpleasant to interoperate with COM

Mono

* “an effort to create an open source implementation
of the .NET Development Framework”

* Runs on Linux

* Includes runtime, compiler, partial class libraries,
various other infrastructure

* http://www.go-mono.com/

* Ximian, the sponsor, recently acquired by Novell

* Questionable legal status given the MS patents

Coming Soon in Java:

* Generics

* Auto-boxing

* for() that works like foreach()

* Attributes

* Typesafe enums

Coming Soon in .NET:

* Generics

* ObjectSpaces (transparent persistance like JDO?
XPath-like access to objects?)

* Async interfaces for many more opertaions

The Pet Shop

* This Sun example web application has been used for
a number of highly publicized benchmarks

* None of them really mean much

* Overall, you’ll get similar performance with Java
and .NET

Markets, Money, and Other Non-Technical Issues

Deployment Platforms

* Java: Almost any

* .NET: Any platform you want, as long as it’s Windows

* To some customers, the first point is a big advantage;
to others, the second is a big advantage.

Open Source

* Lots of activity on both Java and .NET

* Many open Java projects have been ported to .NET.

Jobs

* Java is still apparently far ahead

* St. Louis has a remarkable concentration of large
Java shops

* There are many MS shops here also (and quite a few
MS, and now .NET-centric consulting firms).

* Microsoft technology very popular is small/ medium
sized firms

Market Size

Innovation

* Microsoft can advance .NET and C# forward faster,
because they have less involvement / resistance from other companies

Money – What’s it cost to develop?

* You can develop for either for little or no money

y JDK free download

y .NET Framework SDK free download

* Some features are not in the free downloads

Cost Per Developer

* Java can cost almost nothing per developer per year;
or it can cost several thousand dollars per developer per year.

* Microsoft offers a compelling package with MSDN
Universal

Deployment Cost

* .NET deployment is “free” if you don’t count the
OS

* J2EE can be anywhere from free (Linux + JBoss) to
very expensive (HPUX, AIX + WebLogic or WebSphere, etc.)

* Unreasonable to compare the cost of .NET and J2EE
per se, since the Java cost can vary tremendously by which app server you choose.

The Bottom Line

* More alike than different

* Technically, it’s unlikely that you will succeed
with one and fail with the other

* Java is many places where .NET is not

* .NET is much better integrated with Windows, obviously
the dominant platform for many customers

* Java is a broad market with many producers, while
.NET is very MS-centric.

Talk Offer

* This talk, or one like it with more details

* In your organization

* For Developers

* For Managers

* No Cost (in town)

* No Obligation

XPSTL – Extreme Programming in St. Louis

* Interested? Join the mailing list at xpstl.org

* Worthwhile even if you are only interested in parts
of XP… for example, come learn about test-intensive development.

* Tomorrow night at CAIT, see web site for details.

Questions?

* Experiences?

* Critiques?

* Advice?

Links

* http://www.daimi.au.dk/~beta/ooli/Compare.html

THE END

* Slides will be on my web site,
http://kylecordes.com