A new feature in today's snapshot is that java.lang.Class.getDeclaredFields() now returns the fields in class declaration order for ikvmc compiled code (dynamically compiled code always did this).
This is not required by the specification, but recently after debugging a complex piece of code that failed when compiled with ikvmc because of a field ordering dependency I did some more thinking and came up with a way to cheaply retain the field ordering.
Like Java reflection, System.Reflection makes no promises about ordering, so how do you retain the ordering without adding additional bookkeeping overhead? The key lies in IKVM.Reflection, since ikvmc now uses IKVM.Reflection to emit the metadata I know how to make sure that fields are emitted in a particular order and that this gives them increasing metadata tokens.
So all I had to do is make a minor modification to ikvmc to define the fields in the same order as they are defined in the class file and in the runtime reflection code sort the FieldInfo array returned by Type.GetFields() by metadata token.
Annotations by Proxy
The JDK implements annotations by using java.lang.reflect.Proxy to implement the annotation interface. This is an implementation decision and not promised by the spec anywhere, but predictably there is also code that (for no good reason) assumes that annotations are always implemented by java.lang.reflect.Proxy.
This code failed on ikvmc compiled code, because there I generated .NET custom attributes that implement the annotation interface and simply returned the custom attribute object.
So I've changed the annotation reflection code to now return a java.lang.reflect.Proxy as well (for compatibility, the custom attribute annotations still implement the annotation interface).
You can write whatever you want in the specification, but when an ecosystem is dominated by one implementation, people are going to write against the implementation, not the specification.
This is not just annoying for alternative implementations, but the dominant implementation also suffers, because in subsequent versions you have far less freedom in evolving your implementation.