# Thursday, 23 June 2005
PDC '05

From September 13 thru 16 I'll be in Los Angeles for the Microsoft Professional Developer Conference.

If anyone wants to meet up and hang out or chat, drop me a note.

Thursday, 23 June 2005 15:56:19 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Monday, 23 May 2005
New Snapshot

Partial Trust

I did some research into supporting partial trust and it looks like it might be feasible. This snapshot already contains some changes to better support running in partial trust (particularly for IKVM.GNU.Classpath, IKVM.Runtime contains unsafe code so it currently needs to be trusted). On .NET 1.1 non of the built in partial trust permission sets are suitable, because I require ReflectionPermission(ReflectionPermissionFlag.TypeInformation). In Whidbey this permission flag is deprecated, so the story looks more promissing there.

One of the consequences of adding partial trust support is that IKVM.Runtime.dll will need to be split into several parts. At the very least the JNI implementation will need to be in a separate assembly, so that the common non-JNI scenarios won't require SkipVerification permission.

Exception Handling

I made some major changes to exception handling in this version. However, for Java code nothing should change (except that it hopefully runs a little bit faster), but for .NET/Java interop there are some important changes:

  • Exceptions generated by the CLR or .NET code (e.g. System.NullReferenceException) will no longer be changed into their Java equivalents for non-Java code. This means that when you catch an exception in IKVM Java code, you'll still see the corresponding Java exception (e.g. java.lang.NullPointerException), but when you rethrow the exception, the original exception gets thrown.
  • When Java code explicitly throws a .NET exception (e.g. System.NullReferenceException) it is no longer remapped to the Java equivalent.
  • Catching exceptions now faithfully corresponds to the IKVM type system. This means that you can now use catch(cli.System.Exception) to catch the unremapped .NET exceptions.

This is a major step towards my ultimate vision for exception handling, but I'm not nearly there yet. Other changes I want to make include adding more exception state to java.lang.Throwable instead of the WeakHashMap construct that is currently used (the WeakHashMap will still be required to associate the .NET exceptions with their remapped Java exceptions). I also want to use exception filters to check for remapped exceptions, to make the debugging experience better and the bytecode compiler needs to be improved to recognize try {} finally {} constructs so that they can be compiled as .NET try {} finally {} blocks, instead of the currently used and vastly less efficient try {} catch() { throw; }.

Other News

Mark Proctor reports that Drools runs on IKVM.


  • Sync'ed with GNU Classpath cvs.
  • Removed VMClass.forName() implementation (rely on standard implementation instead).
  • Fixed ikvmc to ignore directories in jars.
  • Added "isStatic" parameter to JNI methods ToReflectedMethod and ToReflectedField (this parameter is missing in the JNI specification, but exists in the Sun implementation).
  • Removed workaround for previously unimplemented MethodBase.GetMethodFromHandle in Mono from JNI code.
  • Removed workaround for previously broken GCHandle.IsAllocated in Mono.
  • Removed workaround for previously broken Assembly.GetTypes() in Mono.
  • Disabled finalizer in MemberWrapper (since code unloading isn't supported, members will never be finalized anyway).
  • Added MirandaMethod to MemberFlags.
  • Fixed cosmetic bug in verifier that caused unloadable array types to be named incorrectly.
  • Implemented 1.5 java.lang.String methods (except String.format()).
  • Added ldsfld instruction support to remapper.
  • Implemented ikvmc -compressresources option, to use a simple compression algorithm for resources.
  • Classpath locale information is now in *.properties files instead of classes with resource compression this shaves a couple of hundred KB of the size of IKVM.GNU.Classpath.
  • Many changes to exception handling to improve performance, compatibility and consistency.
  • Added EditorBrowsable(Never) attribute to helper methods in java.lang.Throwable.
  • Fixed method "cloaking" (i.e. hiding .NET methods on Java types in IntelliSense) to hide inherited static methods as well.
  • Various fixes to work towards supporting running in partial trust.
  • Fixed ikvmc bug that caused it to run Java code when tracing was enabled.
  • Added support for applying CodeAccessSecurityAttribute derived attributes (although not at the assembly level yet).
  • Fixed a Miranda bug that caused incorrect classes to be generated for abstract classes implementing java.lang.Comparable but not implementing compareTo.
  • Implemented support for applying attributes to methods/fields defined in map.xml.
  • Changed reflection to disallow reflecting on IKVM.Runtime types (to avoid potential security holes, where Java code can access internal members of IKVM.Runtime).
  • Enabled generation of debug info when a debugger is attached (at the time the runtime is initializing), to allow debugging of dynamically generated code (a Whidbey feature, although in beta 2 it doesn't work yet).
  • Added check to ikvmc to make sure that referenced ikvmc-generated assemblies were compiled with the same version of the ikvm runtime.

New snapshots: just the binaries and source plus binaries.

Monday, 23 May 2005 11:31:14 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, 18 May 2005
Cross Language Debugging in MonoDevelop

Lluis Sánchez posted some cool screencasts that demo cross language debugging in MonoDevelop [via Miguel de Icaza].

Wednesday, 18 May 2005 14:16:45 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Wednesday, 11 May 2005
IKVM 0.14 Released

I released 0.14 and put the files up on SourceForge. The bits are identical to Monday's rc2.

Wednesday, 11 May 2005 14:43:20 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Monday, 09 May 2005

There's been a lot of confusion about Harmony in the last couple of days. I don't pretend to speak on behalf of the project, but I wanted to give my take on it.

The primary goal of Harmony is to create a J2SE 5 implementation under the Apache License. Many people have interpreted this as meaning that the ASF would start building a JVM and class library from scratch, but that's not the intention at all (although it is a possible worst case scenario). Talks are ongoing between the FSF and ASF to try and work together to change the GNU Classpath license to be compatible with the Apache License. In this light it is important to note that GNU Classpath is already licensed under a modified version the GPL that is more liberal to attract more developers and users. Another thing to note is that the FSF owns all copyright on GNU Classpath (each individual contributor signs over their copyright to the FSF), so the FSF can relatively easily change the license of GNU Classpath (or, for example, dual license it).

In his "Fork in the Open Source Java world" blog entry (a title I obviously disagree with) Miguel argues that the GPL may be a liability instead of an asset for some open source projects. I tend to agree with his view, the GPL and the FSF activism scare many people away, and even with a more liberal license there exist strong motivational factors for companies to work with the community instead of forking a large project and improving only their private version.

As for the pretentious name, all I can say is that I had nothing to do with that :-)

Update: Mark Wielaard corrects me:

And just to correct a little information in Jeroen's latest blog. The FSF/ASF talks are about the general (L)GPL/ASL 2.0 incompatabilities. We do hope to finally solve those since most of them are just legal technicalities and misunderstandings/misinterpretations. (This is something I think is of even more value then this new harmony project).

The current exception statement to the GPL used by GNU Classpath is compatible with and acceptable to the Apache community. But the FSF did say that IF the exception statement was in any way unclear THEN they would certainly be willing to clarify it so that there was no obstacle for adoption of GNU Classpath. There currently doesn't seem any need to do this though.

Monday, 09 May 2005 10:05:34 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
Release Candidate 2

Thanks to M. David Peterson for reporting a regression in rc1. I fixed that and created rc2.


ikvm-0.14-rc2.zip  (source + binaries)
ikvmbin-0.14-rc2.zip   (binaries)


  • Fixed regression in member access check that caused public members inherited from a non-public base class in a different package not to be accessible.
  • Merged ikvm-native FreeBSD compilation fixes from Mono's svn back in.
  • Updated all assembly versions to (including JVM.DLL that I forgot in rc1).
Monday, 09 May 2005 09:24:36 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Monday, 02 May 2005
IKVM 0.14 rc1
GNU Classpath 0.15 was released yesterday, so based on that I'm releasing a new version of IKVM. Besides the many improvements to GNU Classpath, there have been a bunch of IKVM fixes and two major new features: support for defining .NET properties and for applying .NET attributes. Both these features are controlled via the xml remap file. Here's an example Java class with corresponding xml file:
public class IntList
  private int[] list;
  public IntList(int size)
    list = new int[size];
  public void setItem(int index, int value)
    list[index] = value;
  public int getItem(int index)
    return list[index];
<?xml version="1.0" encoding="utf-8" ?>
     <class name="IntList">
       <attribute type="System.Reflection.DefaultMemberAttribute, mscorlib" sig="(Ljava.lang.String;)V">
       <property name="Item" sig="(I)I">
         <getter name="getItem" sig="(I)I" />
         <setter name="setItem" sig="(II)V" />

When IntList.java is compiled to IntList.class and then ikvmc'ed using:

   ikvmc IntList.class -remap:IntList.xml

The resulting IntList.dll will be usable from C# like this:

   IntList l = new IntList(10);
   l[4] = 42;

Valdemar Mejstad created a tool to automatically generate the xml to define properties based on Java's java.beans.BeanInfo. The source is available here: MapFileGenerator.java.


ikvm-0.14-rc1.zip  (source + binaries)
ikvmbin-0.14-rc1.zip   (binaries)


  • Integrated GNU Classpath 0.15 release
  • Dropped support for Mono 1.0.x, because Mono 1.1.x is now the recommended (by the Mono team) version to use.
  • Made some optimizations to System.arraycopy().
  • Removed the previously deprecated ikvm.lang.ByteArrayHack class.
  • Merged fixes to gnu.java.nio.channels.FileChannelImpl from Classpath.
  • Added CLR "bitness" (32 or 64) to ikvm -version output.
  • Fixed ByteCodeHelper.DynamicCast() and ByteCodeHelper.DynamicInstance() to handle null references properly (always succeed/fail the cast/instanceof, without trying to load the type).
  • Changed os.arch for "AMD64" to "amd64" to match JDK.
  • Added sun.arch.data.model system property.
  • Fixed VMThread.suspend()/resume() to not throw exceptions if invalid calls are done.
  • Fixed VMThread.stop() to better handle suspended threads.
  • Fixed a bug in invocation of JNI_OnLoad (if the method exited with a pending exception, the exception wasn't dispatched).
  • Added GC.KeepAlive() to FileChannelImpl.flush() to make sure the file channel isn't GCed (and thus closed) while the native method is running.
  • Fixed verifier to correctly identify stack overflows when double/long values are involved.
  • Fixed verifier to reject empty try blocks.
  • Fixed bug in VMTimeZone.inDaylightTime() [Fix by Alexander Zuev].
  • Fixed a whole bunch of bugs in java.lang.reflect.Field [Reported by Alexander Zuev].
  • Created two subclasses of CompiledTypeWrapper to handle the special cases for remapped and ghost type to make the normal types more efficient.
  • Added a micro optimization to FieldWrapper to avoid having to call FieldInfo.IsLiteral on each reflective field access, because FieldInfo.IsLiteral turns out to be quite expensive on the Microsoft CLR.
  • Removed -monoBugWorkaround switch from IKVM.GNU.Classpath.dll build script, since Mono 1.1.4 and later no longer require it.
  • Fixed bug in protected member access check (it was too strict, requiring the referenced class to be visible).
  • Improved error message when core library doesn't match runtime version.
  • Implemented memory mapped I/O.
  • Added support for defining properties through map.xml file.
  • Added check to ikvmc to prevent signing assemblies that reference unsigned assemblies.
  • Added support for adding custom attributes to assembly, classes, fields, methods and constructors in the map.xml file.
  • Removed -enabletls option from ikvmc (fields can now be marked as thread local by adding a custom attribute).
  • Added AssemblyCopyrightAttribute to IKVM.GNU.Classpath.dll.
  • Fixed a bug in .NET type reflection handling of explicit method implementations.
  • Fixed bug in JNI return value marshaling for methods with boolean return type.
  • Fixed NullReferenceException bug when compiling class with native finalize method.
  • Fixed JNI to continue to work during "finalization for exit".
  • Implemented System.runFinalizersOnExit(boolean). By default, Java finalizers no longer run at application exit.
Monday, 02 May 2005 14:39:33 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Monday, 18 April 2005
Whidbey Beta 2

I downloaded Whidbey Beta 2 from MSDN (subscription required) and installed it on my AMD64 machine (recently repaved with WinXP x64 RTM). Installation went very smooth and IKVM builds and runs its test suite (without requiring the workaround that the Februari CTP needed).

My Very Own Breaking Change

A long time ago I wrote about problems with the C# destructor and used System.WeakReference as example. Recently I discovered a related, but more serious problem with System.WeakReference and reported it to Microsoft.

Here is some evil code:

using System;
class Class1 : WeakReference
    Class1(object obj)
      : base(obj)
    static void Main(string[] args)
        Class1 r = new Class1("foo");
        Class1 clone = (Class1)r.MemberwiseClone();
        new Class1("bar");

The last statement prints out bar. Notice that we aren't supposed to have a reference to bar. This is a variation of a handle recycle attack.

In Beta 2 this problem was "fixed" by adding an unmanaged code inheritance demand to System.WeakReference, so untrusted code will not be able to subclass WeakReference (which is needed to get access to MemberwiseClone). This is a (minor) breaking change, but obviously the right thing to do.

Monday, 18 April 2005 21:04:12 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Monday, 21 March 2005
Saxon.NET RC1

The Saxon.NET developers have announced RC1 of Saxon.NET. I like this project, because it is a good example of the kind of project I envisioned when I started IKVM.NET. They take an existing Java library and convert it to a .NET assembly using ikvmc and they add important value by packaging and testing the converted assembly and by providing examples and utilities.


In unrelated news, I've been able to successfully run my internal test suite on x64 (An AMD64 system running Windows XP Professional x64 Edition RC1 running the Whidbey February CTP). I had to work around one Whidbey February CTP specific bug and had to make a change to VMThread.stop() relating to a Whidbey change in Thread.Abort(). It's too bad there isn't an x64 Windows version of Eclipse yet, because that would make a good real world test.

Monday, 21 March 2005 16:47:35 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
# Wednesday, 02 March 2005
How Not To Fix Bugs

At the moment ikvm/runtime/JniInterface.cs contains the following workaround:

#if __MonoCS__ 
  // MONOBUG mcs requires this bogus fixed construct (and Microsoft doesn't allow it)
  fixed(void** p = &pJavaVM->firstVtableEntry) { pJavaVM->vtable = p; }
  pJavaVM->vtable = &pJavaVM->firstVtableEntry;

Up until Mono 1.1.4 this workaround is required, but current Mono svn has a fixed mcs that doesn't require (nor allow) the workaround.

This means that current IKVM cvs isn't compilable with current Mono svn and that's dumb. The proper way to fix mcs would have been to temporarily (at least until after the next Mono release) allow the incorrect usage of fixed and issue a warning that such usage is illegal and will stop working in a future release.

Wednesday, 02 March 2005 11:05:32 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]