Good morning!
In this post, let me take a few minutes and give you some of the details of what upstream OSS projects have been used in building out Ja.NET SE.
First, if you download and install a Ja.NET SE JDK distribution, you will see that the directory structure looks pretty much like that of a standard Java JDK. For example, if you look in the JDK’s bin directory (i.e. the bin directory for tools), you will see the Java compiler, javac.exe, the Java launcher, java.exe, and other tools you’ll probably recognize from a normal Java JDK distribution. Likewise, you will also see a nested jre folder which includes all the files for both of the runtime environments included in Ja.SE. Remember, Ja.SE includes both a standard Java runtime environment (i.e. JVM) and one that allows you run Java code on the .NET CLR. So where did all that come from?
Well as you might expect, I have not created Ja.NET SE from scratch. To undertake such an effort like this, and to try and do it from scratch would be nuts! Instead, what I have done is base the development work on a few important upstream open source projects. The three largest include Apache Harmony, Eclipse JDT and Mono. Let me give you some details on what and how I use these projects in Ja.SE.
First, the compiler that is included in the distribution is a highly modified batch Eclipse compiler (ecj) from the Eclipse JDT project. I started out with version 3.2, quite some time ago, and have been working on the compiler for a while, but have since upgraded it to be based on the 3.3 version. If you look closely at an installation, you will see ecj_3.3.jar and janet.ecj.dll in the JDK’s bin/lib directories. These are the Java .class files and the corresponding .NET assembly that make up the compiler. The compiler has a backend capable of generating both MSIL and JBC. Of course, the compiler is written in Java and has been compiling itself J for quite some time.
By default the compiler will generate code targeting .NET. It generates PE files (i.e. .NET Asssembly) as its output file format. To create the .NET assemblies, I have incorporated Cecil code from the Mono project into the compilers backend. I’m using a pretty old version (I think 4.3.?); with several modifications (both bug fixes & enhancements). At some point I’ll upgrade to a more current version and contribute all of my fixes or enhancements back to Jb Evain, the author, where it makes sense. BTW, Cecil is written entirely in C#, so if you are interested in seeing how Java in Ja.NET SE integrates/works with C#, take a look at the Ja.SE Eclipse compiler code.
The other development tool that you will see and use quite often during development is bam.exe. Bam (Build Assembly Module) is basically used to "jar up” the assemblies created by the compiler into larger modules, or more correctly .NET assemblies. This improves performance when running on .NET, as loading each class in a separate PE file is a bit too much overhead for applications with a large number of classes. In developing Bam, I started out with some of the code found in Cecil, but have added quite a number of new features and capabilities, such as merging .PDB files and driving the merge using OSGI based manifests. Bam is also written using a combination of Java and C# code.
Now, when it comes time to actually running the code, you end up using the Java launcher from the Apache Harmony project. Harmony been used for a large portion of Ja.NET SE. For example, the class libraries from Harmony serve as the basis for the .NET version of the libraries in Ja.NET SE. One thing that attracted me to Harmony, as opposed to the OpenJDK, is the libraries in Harmony are already organized nicely into modules. For example, you’ll find a LUNI module which stands for Lang-Util-Net-Io, a NIO module, etc. BTW, as a side note, I actually began working with OpenJDK and actually have a running version of that as well on my machine, but chose to switch to Harmony a while back.
So in Ja.SE, each of the Harmony libraries gets translated into a .NET Assembly. If you look in the jre/bin/default directory, you’ll see several janet.xxx.dll’s (e.g. janet.luni.dll). Each one of these provides .NET implementation code for a corresponding Harmony class library module.
Now, when you run the Java launcher, you have the option of loading either the .NET VM or the Harmony JVM, based on command line options. By default, the launcher will load the VM contained in the jre/bin/default folder, which in a Ja.SE distribution, is Ja.NET/.NET. In default, there is a small shim (i.e. harmonyvm.dll) that is used to load up the .NET CLR and start it running. Depending on which VM the launcher starts, the appropriate set of class libraries (i.e. either .NET version or normal Java version), gets loaded and the application is off and running.
So there you have it… Ja.NET SE would not be possible without three important upstream projects, Harmony, Eclipse and Mono.
Dave