Objective
To evaluate the possibilities of Java and .NET framework convergence.
Target Audience
Java programmers and system architects.
Summary
The article begins by briefly probing what constitutes the Java
platform and .NET framework.
Thereafter, I share my
opinionated view of how Java development was shaped, amid the collaborative and
confrontational relationship between Microsoft and Sun. I then stick my neck
out, to predict the future of .NET and Java.
I strongly believe that .NET and Java will converge in near future.
Ten project ideas are discussed for open source implementation to integrate Java
and .NET framework.
The material is
derived from author's own perception of, and experience with, Java since early
1996,Microsoft's
MSDN and Sun
Java site and standard documents
from sites like ECMA and W3C.org.
Overview
Two things may happen between Java and .NET. Either one of them might die or
both might co-exist.
Co-existence is more
likely scenario, because Java has a six years head start and runs on most of the
operating systems. It has a wide support of both Industry leaders like Oracle
and IBM as well as a large repository of Open Source projects covering most of
application domains.
.NET will survive too
since Microsoft has a captive 90% of the desktop OS market. Microsoft has also
adopted Sun's marketing strategy of standardizing the specifications. For
example, for remoting it has proposed SOAP (Simple Object Access Protocol) as a
RFC (Request For Comment) with IETF
(Internet Engineering Task Force) and
W3C (World Wide Web Consortium). It has approached ECMA (European Computer
Manufacturer's Association) for C# and Common Runtime Infrastructure
standardization.
What constitutes the Java platform
The Java platform contains a language called Java, a set of virtual machines
like JVM, KVM and CVM for executing the intermediate byte codes on PCs, Handheld
and embedded systems. Java platform also defines a wide array of API's most of
them correspond and compete with Microsoft's API like JDBC with ODBC, JTAPI with
TAPI, JDO with ADO and so on.
Thus Java platform
consists of a language, a set of runtimes virtual machines and a set of API and
libraries.
The Java had a vision
of single language for all Operating System, and therefore used RMI (Remote
Method Invocation) protocol for remoting. Whereas, Microsoft used DCOM prior to
shifting over to SOAP (Simple Object Access Protocol) with the .NET framework.
Sun initially hyped
that Java was the elusive "Write Once Run
Anywhere" holy grail. After introducing J2EE (Java 2 Enterprise Edition)
and J2ME (Java 2 Micro Edition) it virtually retracted the claim, by admitting
that, the "One Size Fits All" solution does
not work.
What constitutes the .NET framework
.NET framework consists of a set of languages like C++, VB.NET (VB 7.x) and C#
(created by it's Visual J++ team). A runtime environment similar to Java Virtual
Machine and a set of API which is skewed heavily in favor of Windows
architecture. The runtime is hosted within a container which may be a browser, a
web server or an Operating System Shell and in future even the SQL server might
host the runtime.
Microsoft seems to have
dumped DCOM in favor of SOAP (Simple Object Access Protocol); which uses HTTP as
transport and it's syntax is based on XML. SOAP has Java implementation
available athttp://xml.apache.org/.
The Past
In early 1995 when Internet was being transformed into commercial WWW (World
Wide Web), Sunhad
a language and a framework which it had designed for set top TV boxes. This
language was a subset of C++ implemented in 'C' and was called OAK. Sun could
not exploit OAK commercially in the arena for which it was designed. So, Sun
renamed it as Java and made it freely available over the Internet.
Java caught on like wild fire on
Internet, manifesting as fancy Java Applets adorning web pages; viewed mainly on
Netscape Browser. Microsoft under estimated Internet, wishing it away as a
passing fad.
Soon Microsoft
realized that Internet in it's WWW avatar, has the potential to end the
dominance of Windows. "Browser will be the Operating System" became the mantra
often chanted by Netscape. Microsoft therefore now wanted to buy Netscape, but
they refused to sell.
By 1996, Microsoft had
created one of the first stable versions of it's Web browser called Internet
Explorer. Microsoft had no option but to license the Java virtual machine for
it's browser from Sun. At that time, neither Sun nor Microsoft probably realized
that Java will be a greater threat to Microsoft's dominance than Netscape's
browser.
Internet needed a
language and Java could fit the Bill,
and the Gates of
Heaven opened up for Sun. Java being similar to C++, most of the C++
programmers, including me, switched over to Java. It quickly became a religion,
with all it's share of fanatism and rhetoric. Like any religion, it needed a
satan. So the anti Microsoft lobby seized the opportunity to exorcise it's foe,
by taking to Java evangelism.
Ironically Microsoft
stood isolated, even after having produced the fastest and the best Java
compiler and JVM implementation. Much of Java ran and (still runs) on Microsoft
platforms. The fall 1998 MSDN (Microsoft Developer's Network) edition even
claimed that Java was the best language to implement COM components; this claim
was included in the examples of how to create COM components with Java, C++ and
VB.
Parallel to Java,
Linux also was becoming popular and the combination of Linux and Java started to
become a popular choice for server side applications. Apache emerged, and still
retains, the most popular Web server position. These three software combination
hurt the Microsoft NT seriously and restrained Microsoft in the enterprise
server marketplace.
By 1998, dynamic HTML
(DHTML) was standardized under the banner of W3C (WWW consortium) and Java
Script under ECMA (European Computer Manufactures Association). Now all the Java
Applets special effects could be achieved using DHTML. Due to limited modem
speeds, the bandwidth was an issue at that time, this took Applets longer to
download. These two factors routed out Java Applets from most of the web pages.
Java survived this anti Applets wave, since it had firmly entrenched into server
side programming marketplace as well. The open source movement fueled the
popularity of Java. Apache had adopted Java and Servlets and later JSP become
the choice for DOTCOM programers. Interestingly Microsoft lost money by buying a
Java startup having a Java tool called "Liquid
Motion" which provided animation affects on Web pages, much similar to what
is achieved by Flash today
.
Sun and IBM both
having stake on the server hardware market promoted Java and Unix flavors for
Internet and Intranet applications.
Java platform was
extended to enterprise space first with Servlets API followed by JSP (Java
Server Pages) and finally EJB (Enterprise Java Beans). EJB is a Object Oriented
transaction processing system, much similar to Microsoft Transaction Server
(MTS).
EJB (Enterprise Java
Beans) was an industry initiative lead by IBM, Oracle and BEA Logic. They
collaborated with Sun to produce EJB specification to compete with Microsoft
MTS.
Neither EJB nor MTS
could really deliver, since both did not scale upto Internet demands. IBM's Web
Sphere is popular not because of it's EJB compliance, but on IBM's inherent
strengths derived from CICS legacy. Neither was MTS scalable beyond departmental
loads, thus Microsoft quietly folded it into COM+. Incidentally, Microsoft's
.NET documentation imply COM components to be legacy codes, running under
unmanaged code space.
In my opinion, the
worst moment of Java's history was when Microsoft had to pay up Sun, a sum of
USD 20 million, to settle the law suite between them. This become the defining
moment for .NET framework and the beginning of the end to Java's dominance as
the universal Internet platform.
Unfortunately, all
this happened even while Sun was offering Java under open source community
licensing.
Present
The failure of EJB (Enterprise Java Beans) to deliver, made many projects to be
folded up. This was made worst with DOTCOM layoffs, termed by the media as Java
programmers being benched. Now all Java seminars start with a "Java won't die"
theme.
The DOTCOM meltdown
has softened up the "Microsoft Baiter's Club" members. Many neo- natal Java
programmers, just by the virtue of acquiring a Sun Certification, had been
elevated to the status of high temple priests, even when they had NO real
life programming experience. After their ESOPs evaporated, they fell from grace
of their peers. They would be more than willing now, to walk into the .NET
party, to have another go at yet another new language, called C#.
I can see many
training shops drooling at the .NET re-training market place. I would like to
share with you, a first hand experience of my colleague, who attempted to attend
a C# seminar. It was conducted by a private company (not even authorized by
Microsoft) around January 2001, in New Delhi, India. He had to return empty
handed, without attending the seminar. This was because riot police had to be
called to stop the gate crashers, from over crowding the seminar hall !
I recall that the
industry showed similar enthusiasm for Java in the later part of 1995, which was
then just brewing up (sorry no more coffee jokes, and while I am at it, sorry
for the earlier Gates pun as well. Old habits die hard!).
I feel, the US
slowdown for IT will end with the launch of .NET and Windows XP; but this is not
going to happen before the Christmas 2001. Then the ex-DOTCOMMers can don the
robe of DOTNETers and fleece yet another hoard of VCs.
Future
The future will see .NET mature and Java and .NET should converge (I am willing
to stick my neck out on this!). Java should retain it's niche on portable cross
platform server side applications like WAP servers, including telecom domains
like JAIN (Java API for Intelligent Networks), and Java should retain it's lead
on embedded applications like Smart Cards, mobiles and PDA.
.NET Maturity
The .NET platform will mature in due course; much like Java did. And it will be
a rather longish journey.
Oracle 8i and above
acted as an Java runtime host container enabling Java to be tightly coupled
within the Oracle database engine; similarly, the .NET architecture opens up the
possibility for later versions of SQL.NET, containing a Virtual Execution
System (VES) execution engine. This will enable programers to embed C# and VB
inside SQL statements and stored procedures. Currently you can call .DLL
functions using extended stored procedure, but the database itself does not have
a object oriented runtime engine fitted in.
The milestones for
maturity of .NET will be:
- .NET port to popular NON Microsoft server and handheld platforms, like Solaris, Linux and Palm OS.
- Cross integration with Java core. For Example, Java compiler for CLI (Common Language Infrastructure) and C# compiler for JVM (Java Virtual Machine).
- VES (Virtual Execution System) hosted by database systems like SQL.NET and Oracle.
- An Open Source and complete, .NET platform implementation by a neutral third party.
If .NET is to stay on
the track, it should see a lot of startup activities. A few might be funded by
Microsoft or one of it's venture funds. Microsoft can then buy back a few of the
successful ones, at an exorbitant price tag. This would provide a cue to other
VCs' to invest.
Then all those VCs who
had been denied the opportunity to loose money in DOTCOM boom, can move in to
burn their investors' money in new technology startups, in the hope of cashing
in the apparent next generation DOTNET Internet revolution.
Microsoft should also
fund a few open source projects aimed at implementing .NET on Unix platforms.
This funding would also help Microsoft to will win over popular open source
implementors' forum like Apache.org and help them shed their Java bias.
Java's Fate
Java became popular among Telecom equipment providers like Noika, which
implemented it's WAP server in Java. Java still holds it's promise in
telecommunication arena.
Another area of
telecommunications Java is likely to be popular is the telecom industry
initiative called JAIN (Java API for Advanced Intelligent Network see http://java.sun.com/products/jain/).
It was triggered by the need of de coupling switching infrastructure from
service infrastructure. That is, much like pre PC era of 70's and early 80's,
where the hardware manufactures sold custom operating systems along with closed
end applications; Today's telecom infrastructure equipment manufacturers provide
both switching as well as service rendering platforms, which ties down a mobile
network operator with a equipment manufacturer.
Thus the JAIN (Java
API for Advanced Intelligent Network) initiative is defining APIs for telecom
networks independent of protocols like CDMA, GSM or IMT2000, with a vision to
create a component based open marketplace, allowing ISV (Independent Software
Vendors) to provide innovative "plug and work" value added telecom services,
like intelligent 0800 free call redirection to first available nearest
international call center.
With JAIN (Java API for
Advanced Intelligent Network) being supported by major operators and equipment
manufacturers, Java might establish itself in this niche area. However, there
are a few hurdles in this arena for Java, like Microsoft and BT (British
Telecom) initiated open specification project called Parlay (http://www.parlay.org./).
This was supported by the industry as well, and predates JAIN. The industry is
probably hedging it's bets on both the platform, till a clear winner appear or
until both platforms merge. JAIN and Parlay groups have overlapping memberships
(with exceptions of Sun and Microsoft off course) and they seem to be
collaborating now.
The Java might also
retain a lead in embedded applications like smart 3G and GPRS enabled mobile
phone having J2ME (Java 2 Micro Edition) implementations. However, if it does
not rectify the current load time delays it might be taken over by C#, if .NET
provides a faster execution environment and wide spread industry support.
Much like PC hardware
scenario of late 80's, when IBM held the lion's share of PC desktop hardware,
Nokia today holds about 70% of the mobile handset market. Thus if Nokia gets
sold over the .NET micro edition, then Java has had it.
.NET and Java convergence
The inevitability of a convergence between Java and .NET platforms is a foregone
conclusion and a necessity. The necessity arises because both the platforms need
each other to survive. Microsoft designers themselves stress the need to reuse
existing codes to safeguard their own investments and I am sure they will apply
the same logic on other's investments as well.
Apart from this
commercial necessity, the intellectual need of the programmers will be
satisfied by devising and designing convergence strategies, and open source
implementations of the same.
So let us indulge
ourselves into few of such possible projects for converging Java and the .NET
framework: (they have been categorized in groups A,B,C to indicate dependencies
within the projects, though each project can be executed in parallel).
- JVM to CIL compiler (Group A)
- Java API bridge for .NET API and lib. (Group A)
- Java compiler for CLI (Group A)
- CLI ports for Palm OS, Linux and Solaris (Group B)
- .NET API and lib. bridge for Palm OS API (Group B)
- .NET API and lib. bridge for POSIX (Group B)
- CIL compiler to JVM (Group C)
- .NET API and lib. bridge for Java API (Group C)
- C# compiler for JVM (Group C)
Each group contains
one project each for compiling one virtual machine to another another from the
binary file itself. Another for mapping one set of APIs to another and finally a
compiler which targets code directly for the cross platform.
Each of the above
proposed project ideas are outlined below.
[The next section contains technical details and
can be skipped without a loss of continuity. Click
here, to jump straight into "Conclusion", section (no pun intended).
This section assumes that you are familiarity with both Java and .NET framework
architecture. If you are not familiar with Dot Net architecture, you might find
it helpful to refer my article titled ".NET
Framework for Java Programmers" for a .NET architecture overview.]
Group A Projects
The proposed Group A projects will allow existing Java binary codes to
execute on .NET platform.
Group A projects will
bring Java into the domain of CLI (Common Language Infrastructure). That is
existing Java programs in binary format (that is, directly .class files) would
be able to run on .NET platforms, without being recompiled from source files.
Although the .class files would need to be transparently compiled during
installation or execution just like Microsoft .NET runtime and JIT do to MSIL
(Microsoft Intermediate Language) binary codes contained in PE (Portable
Executable) format having .EXE, .DLL or .MSI extensions.
JVM to CIL compiler
This proposed compiler can be ideally implemented in either Java or C#. This
compiler will take a JVM .class file as input and produce a CIL (Common
Intermediate Language, also called MSIL by Microsoft) output. Thus this CIL can
be used by tools like ilasm.exe (the
Microsoft .NET SDK intermediate language assembler) to produce PE (Portable
Executable) formatted files like .EXE, .MSI or .DLL files.
Java API bridge for .NET API and lib.
The Java API bridge for .NET API will map the Java APIs to their corresponding
.NET API for example Java API's java.io.File will
get mapped to .NET's System.IO.File class.
The IO lib. will be the easy bit. The complexity will arise in mapping the
java.net package with the.NET's System.Net
Ironically enough,
this project should ideally be implemented in C#. However, it can be implemented
in java, if a Java compiler is available which directly targets the CLI (Common
Language Interface) and generates CLS (Common Language Specification) compliant
CIL (Common Intermediate Language) codes.
A lot of dog work can
be avoided for such bridge coding by writing a wizard like tool, for example you
could write a tool in Java or C# which takes an a XML formatted object
description (for XML formatted object description refer to SOAP, Simple Object
Access Protocol specification is available athttp://www.w3c.org/)
and generate skeleton codes, which can be filled by the programmer later by
hand, if required.
If you plan to write
such a tool, you will find a lot of usable code from within the Java
implementation of SOAP gateway available at (http://xml.apache.org/)
The Microsoft Java
SDK, which is a bit out dated now, contained an innovative tool for creating JDirect(JDirect was
the Microsoft's hack for implementing native interfaces) codes for accessing
native Win32 API. The samples in that SDK also contained the tool's source code.
The JDirect implementation
required an Microsoft specific extension to Java compiler markup syntax, this
was one of the contentions of the law suite which ensued between Sun and
Microsoft.
Java compiler for CLI
The Java compiler for CLI would compile the source codes written in Java (but
using the .NET API's) to be compiled into PE (Portable Executable) formats like
.EXE, .DLL and .MSI.
This project would
create a final source level integration of Java with .NET framework; paving way
for future .NET applications to be written in Java, using the .NET API directly.
Such a Java compiler
may be implemented rather quickly, by refitting the code generation part of the
many Java compilers available currently in open source. The best design, in my
opinion, is that of newly re-written Java compiler in Java itself, available
from Sun ( has to be the best, coming directly "from the Source") under open
community source license.
However, such an
approach of retrofitting an existing Java compiler, would require some
re-engineering to remove the class loading and library classes dependencies like java.lang classes.
Group B Projects
The Group B projects aim at porting .NET framework to open source platforms at
Palm OS at one end and Solaris and Linux at the other end.
The ports would more
often be implemented in 'C' for speed and control. Also 'C' remains the language
of choice for such OS related systems level programming.
CLI ports for Palm OS, Linux and Solaris.
This proposed project would port the .NET framework runtime to Palm OS and Unix
clones. Actually it would consists of two separate projects. One for Palm OS and
other for Unix flavors.
The Palm OS
implementation can be implemented in Java itself with all of the implementation
sitting outside the Palm OS and actually residing on the PC environment and
communicating and uploading the compiled binary codes in native .PRC format
through HotSync cable or Bluetooth link. This will bypass resource constrains of
the Palm OS and speed up execution speeds. This inherently assumes that
availability of a subset of .NET API for Palm OS described in the next section.
The Solaris and Linux
ports can be implemented in Java, which compile PE (Portable Executeable) files
to COFF (Common Object File Format ), unix executable images.The compilation can
take place during installation or at load time. Both these ports would assume
that Win32 dependent portions are not used and the binary code does not contain
or access any unmanaged codes.
.NET API and lib. bridge for Palm OS API.
This .NET API bridge has to be ingeniously deviced as the API calls has to be
mapped to the Palm OS API in a resource optimized manner. The linker and loader
mapper would probably reside on a gateway at PC, transferring the Palm
executable code through HotSync link over a serial cable, irDA or Bluetooth
link.
The implementors of
such bridge must first study the implementation of KVM (the Java 2 Micro
edition) runtime for Palm OS resident virtual machine; and should avoid a few
pitfalls of KVM design, which make the Java executables load much slower,
flouting the acceptable loading response times bench marked by Palm Inc.
The subset of the .NET
API can be bench marked against the .NET API for Windows CE platform which leave
out few resource hungry API like System.Xml .
.NET relies on SOAP
(Simple Object Access Protocol) for remote method calls or remoting. SOAP being
an XML syntax compliant relies on System.Xml API.
Thus without an XML parser engine the SOAP based distributed applications can't
work.
To implement remoting
from PDA like Windows CE or Palm OS hosted application and server side
applications residing on Windows 2002 or Linux; one can device a transparent
stub or a hook activated from calls to System.Xml API
methods. These stubs would then use WBXML (Wap Binary XML) standards of WAP
(Wireless Access Protocol see http://www.wapforum.org/ )
to communicate with a customized WAP gateway catering to SOAP. But then that's
another project idea!
.NET API and lib. bridge for POSIX.
The .NET API bridge for POSIX would map the .NET and Unix API's. Though it would
be a lot of work in 'C', the worst nightmares would occur while implementing the
GUI elements.
Unix flavors have
multiple GUI frameworks, however the safest would be to provide an intermediate
Win32 API port for Unix platform. I am vaguely aware of such Win32 mappers for
Linux and Solaris. If such a Win32 API is used then much of the coding can be
saved by using an automatic mapping tool similar to one provided in the previous
versions of Microsoft's Java SDK, described above.
Group C projects
The Group C projects would target the .NET framework to work on Java. All but
die hard Java fanatics would attempt such a project. Since a full port is not
possible due to the extended and Win32 architecture dependencies built into the
.NET platform.
However, such projects
would be more practical by attempting to implement the standards specifications
submitted to ECMA by Microsoft.
CIL compiler to JVM
This proposed project would create a compiler converting the PE (Portable
Executable) format binary files and convert it to .class file format. However,
the executable containing any legacy or unmanaged codes, can not be ported into
JVM. A hook from Java can be derived using the Class Loader API.
This project presumes
the implementation of .NET API bridge for Java described below.
.NET API and lib. bridge for Java API.
A fully compatible .NET API bridge may not be possible so the implementors must
stick to the parameters of the ECMA standards proposed by Microsoft.
This bridge may be
implemented in Java. But, it will involve much more dog work that the Group A
project Java API to .NET bridge suggested above.
C# compiler for JVM
The C# compiler for JVM (Java Virtual Machine) can be implemented both in Java
or C#.
This should be ideally
attempted to be written in Java. You can then re use much of the Sun's Java
compiler (written in Java itself, without using any compiler's compiler tools
like Java
Cup or yacc)
available under community license.
However, for more
adventurous, I would suggest C#. There are a few basic level compiler examples
included in .NET SDK in tool's developer samples section.
This project presumes
the implementation of .NET API bridge for Java.
Conclusion
My advice to all my peer Java programmers would be: It is time for a reality
check, so stop cracking those stupid (sipping the)
coffee and (paying the) Bill jokes, because,
after Bill Joy, the next one to fit the Bill will be Mr. Gates himself, with His brand
new G(re)ate crashing .NET platform. (yes! I know, I broke my earlier promise
of no more Bill jokes, but then, didn't I warn you that old habits die hard?).
And now, let's start
looking seriously at converging the .NET framework with Java. Neither Sun nor
Microsoft will do it for us. Open source initiatives will be a viable class
action by the free thinking programmers, to integrate Java and .NET framework.