Integrating Java and .Net Framework

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.