One of the “features” I added sometime ago is a “hybrid binary packaging" approach that allows someone to build a single binary of a Java based application or library which can be used with a regular JVM or with .NET (ala Ja.NET SE). So I thought I would be good to blog about what that is and how it works. First, a little background:
So, as I’m sure you are aware, in the .NET world, libraries or applications (i.e. code, resources, etc.) are always packaged up and distributed in a container called an Assembly (i.e. .dll). The .NET runtime and all of it's associated tools (i.e. CLR, C# compiler, etc.) have been built to expect this type of packaging. Contrast that with the Java world, in which an application’s classes and resources can be loosely packaged in directories or can be “jarred up” into multiple .jar files, or a combination of both. And, just like with .NET, all of the Java runtime and tools (i.e. JVM, class loaders, class libraries, tools, etc.) all support and expect this kind of packaging.
So, with Ja.NET I have needed to come up with a way to allow for both packaging approaches to coexist. That is to say, I have had come up with a way to satisfy the expectations of the .NET runtime and tools as well as the approach used in the Java environment. Since code and resources are packaged in .NET assemblies, essentially, I needed Ja.NET to be able to consume (i.e. read, run, etc.) .NET assemblies natively, in addition to the normal Java packaging I mentioned above, and, likewise if you want to be able to use the Java code natively in any .NET application, Ja.NET must be able to produce .NET assemblies compatible with all of .NET. So here is what I have implemented thus far:
First, all of the Ja.NET SE tools produce .NET assemblies as output. The javac compiler will emit a filename with a .class extension, but that is a .NET assembly, not a normal java .class file. The bam tool will merge these .class assemblies into one larger DLL assembly. All of these assemblies are then compatible with the .NET runtime and tools in the .NET world. So, for example you can take the .DLL produced from bam and reference it in a C# project in Visual Studio.
Second, one of the basic philosophies I have tried to use throughout Ja.NET SE (i.e. both tools and runtime) is to try and treat .NET assemblies (i.e. .DLL’s) much like the native Java/JVM runtime and tools treat .jar files (i.e. as containers for .class files and resources). So the idea I have tried to implement through out, is that any place that you can use or reference a .jar file in the normal Java JVM/tools world, you should be able to use or reference a .NET assembly DLL when using Ja.NET. So for example, with the Ja.NET javac compiler, you are able to include .NET DLL's (i.e. –cp PresentationFramework.dll;System.dll) on the classpath, in addition to .jar files. Or, when starting up a Java based application on .NET using the Ja.NET java launcher, you are able to add assemblies to the launchers –classpath, much like you can add .jar files.
Third, there is a unique “hybrid packaging” approach which is supported by Ja.NET that enables you package up a single Java library or application binary which can run on both a regular JVM as well as .NET. The packaging contains both the JVM .class files which you would include normally, as well as a set of corresponding .NET assemblies for running the library or application on the CLR.
Basically, what you need to do to leverage this and build one of these “hybrid packaged” binaries is to package up your application or library like you normally would (i.e. a set of .jar’s or loose in directories or both). Then to turn the packaging into a “hybrid”, you need to weave into the packaging, in a well defined way, the .NET assemblies that go with the JVM binaries. The way you do this is for each .jar file that contains JVM .class files and resources, you need to include in the root of the .jar, a corresponding .NET assembly that contains all of the .NET implementation code for those .class files and any resources. And, likewise, for directories, you need to you need to include at the root of the directory, a .NET assembly containing all the implementation code for those JVM classes.
The Ja.NET runtime and tools support this "hybrid packaging" structure today. So for example, if you have a “hybrid” .jar file that represents a library, and you have some Java code that references this library and you want it to run on .NET, you can simply include the .jar on the javac class path, and the Ja.NET SE compiler will find the library's .NET assembly in the .jar and inlcude it when compiling the Java code. Then also at runtime the Ja.NET SE class loading infrastructure has been updated to support this same structure, and will also be able to find the .NET assembly in the .jar file and load it at runtime simply by including it on the classpath of the Java launcher tool.
Now, you might be thinking at this point, this is a kind of a pain. In order to take advantage of this, I’m going to have to go through and modify my Ant build scripts to do this “unique” packaging. Well the good news is that all of this is built into the Ja.NET development tools, runtime, and by downloading the Ja.NET-SE-Additional Development Tools.zip, from the sourceforge.net web site, you can easily leverage all of this with no need to modify your Ant build scripts.
Next, I’ll do a blog with and example on how easy this can be done ...
Dave