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 at http://xml.apache.org.
The Past
In early 1995 when Internet was being transformed into commercial WWW (World Wide Web), Sun had 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 at http://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.