While the 0.44 release candidates have been baking, I've been working on 0.45. There are some interesting changes related to resource handling and stub classes.

Resources

 Previously, if you looked at the URL returned by ClassLoader.getResource() for an ikvmc compiled assembly you see something ugly like this:

 ikvmres://IKVM.OpenJDK.Jdbc,%20Version=0.44.0.5,%20Culture=neutral,%20PublicKeyToken=13235d27fcbfff58/META-INF/services/java.sql.Driver

Now with 0.45, you see:

jar:file:/C:/.virtual-ikvm-home/assembly/IKVM.OpenJDK.Jdbc__0.45.3887.0__13235d27fcbfff58/resources/resources.jar!/META-INF/services/java.sql.Driver

This is also a bit strange, because C:\.virtual-ikvm-home doesn't actually exist, but it is the IKVM Virtual File System directory that was introduced with the switch to OpenJDK, to facilitate the fact that OpenJDK likes to load lots of files from the installation directory.

Starting with 0.45, the virtual file system is also used to load resources and stub classes. When you compile your jar with ikvmc, the resources in the jar will be copied into a new jar (usually with the same name) and that jar will be attached as a managed resource to the target assembly. This resource is projected into VFS and the normal Java resource loading mechanism is (more or less) used to load resources from the jar.

This has two main advantages. The first is that this makes it more likely that Java code that makes various assumptions about being being able to explicitly open a resource jar, will work. The second is that this method of storing resources, usually results in smaller assemblies.

Another benefit of this change is that I finally fixed the issue with ikvmc skipping resources due to name clashes. Previously there was only a single resource namespace per assembly, but now an assembly can contain multiple resource jars.

Stub Classes

Some Java code requires .class files for system classes. This is usually because they want to do dynamic code generation and Java's reflection isn't really good enough for that. For a long time IKVM has supported this by dynamically creating the .class files (in a runtime equivalent of ikvmstub) whenever code tried to load a resource that ended with .class and a corresponding type was found. This used the same ikvmres protocol mechanism as normal resources. With this snapshot, the stub classes have also moved to VFS. They are still generated on demand, but they are now accessible via the Java file IO APIs. This means that the sun.boot.class.path property can now point to VFS and that Java code, like javac, that depends on sun.boot.class.path will now work.

You can now build a working javac.exe like this:

ikvmc -main:com.sun.tools.javac.Main -out:javac.exe -r:IKVM.OpenJDK.Tools.dll

The resulting javac.exe will be very small (4KB), because all the code is in IKVM.OpenJDK.Tools.dll (the equivalent of tools.jar).

Changes:

• Fixed java.util.zip.Inflater to throw exception for corrupt zip files (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36560).
• Added the ability to nest ikvmc response files and added error handling to response file reading.
• Made most ikvmc warnings local to the target that is being compiled (in multi target mode), to allow warnings to be suppressed (or turned into an error) for a specific target.
• Added -writeSuppressWarningsFile: ikvmc option.
• Added support for comment lines in ikvmc response files.
• Volker implemented Window.setMinimumSize().
• Massive change to change resource handling. Java resources are now stored in jars that are stored as managed .NET resources. The jars are projected into VFS and the assembly class loaders know how to load resources from these jars.
• Volker added support for "My Computer" folder.
• Volker fixed a regression in Toolkit.createImage(ImageProducer).
• Fixed build to work when Mono isn't installed.
• Stub classes are now projected into VFS.
• Stub classes (as resources) are no longer generated if a resource with that name already exists in the assembly.
• System property "sun.boot.class.path" now points to stub classes in VFS.
• Removed the requirement to have peverify and ilasm in the PATH. They are now located automatically and if they are not found, the corresponding build steps are skipped.
• Separated managed and native build steps and made managed the default target. This allows doing a build with "nant" with just nant and JDK 1.6 in the PATH.
• Changed default build target to automatically generate a CommonAssemblyInfo.cs with todays build number.
• Fixed java.lang.ref.Reference to not store a strong reference to java.lang.Class objects, if class GC is enabled. Note that class GC is only available on .NET 4.0 and when IKVM is specifically built for .NET 4.0.

Binaries available here: ikvmbin-0.45.3887.zip