 |
|
Tools Main |
|
|
|
Tools Main |
If you are familiar with .NET, you already know that within .NET an assembly provides the fundamental unit for deployment, version control, code reuse, scoping, and security permissions. It provides .NET developers a deployment mechanism in which a collection of classes and resources that have been built to work together can be combined into a deployable unit of functionality. In fact, to the .NET runtime, a class does not exist outside the context of an assembly, and at runtime, all classes in a .NET application are scoped to their containing assembly. To ensure the best level of compatibility with .NET, we have adopted the .NET assembly as the primary distribution format for Java classes within Ja.NET.
When using Ja.NET you will find time and time again that you are working with assemblies. For example, whenever you use the Java compiler included with Ja.NET, you are creating assemblies. By default, the Ja.NET SE compiler creates a single assembly file for each Java class that it compiles. The name of the file it produces is the same as the class name, but with a ".class" filename extension instead of .DLL (e.g., Class.class, Class$1.class, etc.). The display name of the assembly assigned by the compiler is the name of the fully qualified class name it produces concatenated with the string ".class" (e.g. "java.lang.Class.class", "java.lang.Class$1.class", etc.). Since these are valid .NET assemblies, they can be loaded into the .NET runtime and executed, just like any other .NET assembly produced by other .NET compilers or tools.
Another example, where you will be working with assemblies occurs when you use the Build Assembly Module (bam) tool provided with Ja.NET SE. Bam is a tool you use to combine the class oriented assemblies produced by the Ja.NET SE Java compiler into larger assemblies containing multiple classes. In a way, bam serves the same role in development as jar does on a standard Java platform, except in combines the .class files into an assembly (i.e., .DLL) instead of a .jar file.
In order to accommodate the usage of .NET assemblies within Ja.NET Se, we have found it necessary to extend the semantics of a few APIs and settings found in a standard Java platform. For example, we have extended the syntax and semantics of the Java class path such that you can now include assemblies on the class path much like you do directories, and jar files. If a file with a .DLL extension is included on the class path, the JDK tools (e.g., launcher, compiler) and the Ja.NET SE system class loader treat the file as if it is a .NET assembly and, attempt to open it and use it as a source for class resolution, much like they do with .jar files. If any error occurs when opening the assembly, it is simply ignored and will not be used by the tool or runtime.
Likewise, we have also extended the semantics of the "defineClass(...)" method within ClassLoader. In addition to supporting a byte array containing a class file, we have also added the ability to define a class contained in an assembly. To do this, you supply a valid .NET assembly in the byte array, instead of a class file, and the Ja.NET SE runtime will load the assembly into the process. If successful, the assembly will become associated with the class loader that defined it. Any further requests to the class loader to resolve a class will cause the assembly to be searched, along with any other assemblies the loader has associated with it.
So, as you can see, .NET assemblies play a significant role when using Ja.NET. To get a better understanding of how class loaders, assemblies, and class resolution all work together, read these sections on How Assemblies are Found and How Classes are Found.