Compiler Creates Assemblies

Continuing on with our example, let's look a little closer at what the compiler generated. What you should see is that two '.class' files have been created in your current directory, 'MyProgram.class' and 'HelloWorld.class'. If you've done Java development before, you know that this is exactly what you'd expect to see. 

But, there is an important difference between the '.class' files created by the Ja.NET SE compiler and those created by a standard Java platform compiler. When you use the Ja.NET SE compiler, it, by default, generates code and class files for the .NET runtime instead of a standard Java platform.  What this means is the  compiler actually produces .NET assemblies for each of the compiled classes rather than the normal Java '.class' files containing Java byte code. Each file is formatted internally as a .NET DLL and contains the Microsoft Intermediate Language (MSIL) implementation of the class, rather than the Java byte code implementation. Obviously, these files are not compatible with a standard Java platform and would not be usable on any of the popular platforms, such as Sun's, Apache's or Oracle's. 

As a side note, if you want the compiler to generate code for a standard Java VM instead of .NET, you can optionally add the “–java” command line option. This will cause the compiler to generate standard '.class' files with Java byte code instead of MSIL.

Launcher Runs Assemblies

If we take a little closer look at what it took to run the program we created earlier on .NET,  you can see that we were able to use a Java launcher, much in the same way you do today with other standard Java platforms, to load and start the application. You simply referenced the class that has the main() method in it, exactly as you would have done when using a standard platform. The important difference here is that the launcher started the .NET runtime and loaded the compiled assemblies, rather than starting a JVM and loading standard Java ".class" files.

Actually, the Java launcher included in Ja.NET SE is able to run applications on either .NET or the included standard Java platform, Apache Harmony. By default, the launcher will attempt to run the application on .NET, but if you've used the javac “-java” option mentioned above, you can also use the same launcher to run the application on the Harmony JVM by including the “–vmdir:drlvm” option. Of course if you tried this with our current example you'd see a NoClassDefFoundError since the System.Console class could not be found by the Harmony JVM at runtime.

Next, let's explore in more depth how you work with assembies in Ja.NET SE by taking a look at a new tool specifically built for Ja.NET SE, the bam tool (Build Assembly Module) .