# Monday, 10 December 2012
IKVM.NET 7.2 Released

I've released IKVM.NET 7.2 to SourceForge and NuGet. The binaries are identical to the ones in release candidate 5.

Release Notes

This document lists the improvements, known issues and incompatibilities.

What's New (relative to IKVM.NET 7.1):

  • Integrated OpenJDK 7 u6 b24.
  • Improved java.util.concurrent performance.
  • Removed org.omg.PortableInterceptor.UNKNOWN class, that is not part of [Open]JDK rt.jar.
  • Added ZipFile constructor that was added in Java 7.
  • Add support for running with headless awt toolkit.
  • Changed ikvmc to apply custom attribute annotations on annotation types to the corresponding custom attribute that is generated (and allow AttributeUsageAttribute to override the default AttributeUsageAttribute generated from the @Target annotation).
  • Added app.config files for executables to allow them to run on .NET 4.5 on Windows 8 without triggering the .NET 3.5 auto download.
  • Added (optional) support for building without System.Core.dll dependency.
  • Disabled AppDomain.ProcessExit hook to run shutdown hooks when running on Mono to workaround https://bugzilla.xamarin.com/show_bug.cgi?id=5650.
  • Several verifier fixes.
  • Several metadata reflection fixes.
  • Fixed two try/finally block code gen bugs.
  • Various other minor fixes.
  • IKVM.Reflection: Many minor bug fixes and improvements.
  • IKVM.Reflection: Added most new .NET 4.5 APIs.
  • IKVM.Reflection: Added experimental support for generating Windows Runtime (.winmd) assemblies.
  • IKVM.Reflection: Added missing DefineResource() APIs to ModuleBuilder and AssemblyBuilder.
  • IKVM.Reflection: Added co-/contra-variance support to Type.IsAssignableFrom().
  • IKVM.Reflection: Added support for using the .NETCore v4.5 aka Metro profile mscorlib.dll.
  • IKVM.Reflection: Added UniverseOptions.DisablePseudoCustomAttributeRetrieval to disable returning pseudo custom attributes.
  • IKVM.Reflection: Bug fix. Ignore unknown metadata streams.
  • IKVM.Reflection: Bug fix. Set AddressOfRawData in IMAGE_DEBUG_DIRECTORY.

Runtime

  • Code unloading (aka class GC) is not supported.
  • In Java static initializers can deadlock, on .NET some threads can see uninitialized state in cases where deadlock would occur on the JVM.
  • JNI
     
    • Only supported in the default AppDomain.
    • Only the JNICALL calling convention is supported! (On Windows, HotSpot appears to also support the cdecl calling convention).
    • Cannot call string contructors on already existing string instances
    • A few limitations in Invocation API support
       
      • The Invocation API is only supported when running on .NET.
      • JNI_CreateJavaVM: init options "-verbose[:class|:gc|:jni]", "vfprintf", "exit" and "abort" are not implemented. The JDK 1.1 version of JavaVMInitArgs isn't supported.
      • JNI_GetDefaultJavaVMInitArgs not implemented
      • JNI_GetCreatedJavaVMs only returns the JavaVM if the VM was started through JNI or a JNI call that retrieves the JavaVM has already occurred.
      • DestroyJVM is only partially implemented (it waits until there are no more non-daemon Java threads and then returns JNI_ERR).
      • DetachCurrentThread doesn't release monitors held by the thread.
    • Native libraries are never unloaded (because code unloading is not supported).
  • The JVM allows any reference type to be passed where an interface reference is expected (and to store any reference type in an interface reference type field), on IKVM this results in an IncompatibleClassChangeError.
  • monitorenter / monitorexit cannot be used on unitialized this reference.
  • Floating point is not fully spec compliant.
  • A method returning a boolean that returns an integer other than 0 or 1 behaves differently (this also applies to byte/char/short and for method parameters).
  • Synchronized blocks are not async exception safe.
  • Ghost arrays don't throw ArrayStoreException when you store an object that doesn't implement the ghost interface.
  • Class loading is more eager than on the reference VM.
  • Interface implementation methods are never really final (interface can be reimplemented by .NET subclasses).
  • JSR-133 finalization spec change is not fully implemented. The JSR-133 changes dictate that an object should not be finalized unless the Object constructor has run successfully, but this isn't implemented.
  • Strict class-file checking is not implemented.
  • If a class with a finalizer and static initializer allocates instances of itself in the static initializer and the static initializer subsequently fails, the .NET runtime may abort the application when trying to finalize the objects.

Static Compiler (ikvmc)

  • Some subtle differences with ikvmc compiled code for public members inherited from non-public base classes (so called "access stubs"). Because the access stub lives in a derived class, when accessing a member in a base class, the derived cctor will be run whereas java (and ikvm) only runs the base cctor.
  • Try blocks around base class ctor invocation result in unverifiable code (no known compilers produce this type of code).
  • Try/catch blocks before base class ctor invocation result in unverifiable code (this actually happens with the Eclipse compiler when you pass a class literal to the base class ctor and compile with -target 1.4).
  • Only code compiled together during a single compilation fully obeys the JLS binary compatibility rules.

Class Library

Most class library code is based on OpenJDK 7u6 build 24. Below is a list of divergences and IKVM.NET specific implementation notes.

com.sun.security.auth.module        Only implemented on Windows.
java.applet Not implemented.
java.awt Partial System.Windows.Forms based back-end. Not supported.
java.io.Console Not implemented.
java.lang.instrument Not implemented.
java.lang.management Limited implementation.
java.net SCTP and SDP not implemented.
java.net.ProxySelector Getting the default system proxy for a URL is not implemented.
java.nio.file Most optional features (e.g. ACLs) are not implemented.
java.text.Bidi Not supported.
java.util.zip Partially based on GNU Classpath implementation.
javax.crypto ECC is not implemented.
javax.imageio.plugins.jpeg Partial implementation. JPEGs can be read and written and there is limited metadata support.
javax.management Limited implementation.
javax.print There is a Win32 specific printing implementation. Not supported.
javax.script ECMAScript implementation is not included.
javax.smartcardio Not implemented.
javax.sound Not implemented.
javax.swing Not supported.
javax.tools Not supported.
org.ietfs.jgss Not implemented.
sun.jdbc.odbc Implementation based on .NET ODBC managed provider.
sun.net.www.content.audio Audio content handlers not implemented.
sun.net.www.content.image Not supported.

The entire public API is available, so "Not implemented." for javax.smartcardio, for example, means that the API is there but there is no back-end to provide the actual smartcard communication support. "Not supported." means that the code is there and probably works at least somewhat, but that I'm less likely to fix bugs reported in these areas, but patches are welcome, of course.

Specific API notes:

  • java.lang.Thread.stop(Throwable t) doesn't support throwing arbitrary exceptions on other threads (only java.lang.ThreadDeath).
  • java.lang.Thread.holdsLock(Object o) causes a spurious notify on the object (this is allowed by the J2SE 5.0 spec).
  • java.lang.String.intern() strings are never garbage collected.
  • Weak/soft references and reference queues are inefficient and do not fully implement the required semantics.
  • java.lang.ref.SoftReference: Soft references are not guaranteed to be cleared before an OutOfMemoryError is thrown.
  • Threads started outside of Java aren't "visible" (e.g. in ThreadGroup.enumerate()) until they first call Thread.currentThread().
  • java.lang.Thread.getState() returns WAITING or TIMED_WAITING instead of BLOCKING when we're inside Object.wait() and blocking to re-acquire the monitor.
  • java.nio.channel.FileChannel.lock() shared locks are only supported on Windows NT derived operating systems.
  • java.lang.SecurityManager: Deprecated methods not implemented: classDepth(String), inClass(String), classLoaderDepth(), currentLoadedClass(), currentClassLoader(), inClassLoader()

Supported Platforms

This release has been tested on the following CLI implementations / platforms:

CLI Implementation       Architecture      Operating System
.NET 2.0 SP2 x86 Windows 8
.NET 2.0 SP2 x64 Windows 8
.NET 4.5 x86 Windows 8
.NET 4.5 x64 Windows 8
Monday, 10 December 2012 07:51:13 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Thursday, 06 December 2012
IKVM.NET 7.2 Release Candidate 5

Apologies for the ridiculous delay. I've been busy. This is the final release candidate.

Changes (relative to rc 4):

  • Updated version to 7.2.4630.5
  • Bug fix. The static compiler cannot use a different way to encode erased array types than the runtime compiler (because otherwise the runtime can't override statically compiled methods).
  • Added missing SecuritySafeCritical attribute.

Binaries available here: ikvmbin-7.2.4630.5.zip

Sources: ikvmsrc-7.2.4630.5.zip, openjdk-7u6-b24-stripped.zip

Thursday, 06 December 2012 10:13:45 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Thursday, 01 November 2012
JDK 7 Thread Cloning Vulnerability

This blog entry was originally posted on June 23, 2011, but was deleted as Oracle asked me to take it down while they investigate. After more than a year, the issue still has not been addressed, so I notified Oracle that I wanted to repost the blog entry and received no response. -- Jeroen

I warned on the mailing list when this came up, but apparently was ignored,so maybe a blog post will help.

In one of last year's updates of JDK 6 the cloning vulnerability was fixed in a hackish, but clever and safe way. Now in JDK 7 they try to fix it by overriding Object.clone() with a version that simply throws CloneNotSupportedException. The only problem is, in Java (and .NET too) overriding a method is not a safe way to make the base class method unavailable.

The (still) not so well known ACC_SUPER flag allows you (when it isn't set) to call arbitrary (accessible) methods in your super class hierarchy. So Thread.clone() can be skipped and Object.clone() can be called from any Thread subclass that doesn't have the ACC_SUPER flag set.

Here's an example:

class Clone extends Thread implements Cloneable {
  public Object clone() {
    try { return super.clone(); }
    catch (CloneNotSupportedException _) { throw new Error(); }
  }
}

class Demo {
  public static void main(String[] args) throws Throwable {
    Clone c1 = new Clone() {
      public void run() {
        for (;;) {
        }
      }
    };
    c1.start();
    Thread t = (Thread)c1.clone();
    c1.stop();
    c1.join();
    System.gc();
    t.stop();
  }
}

Note that after you compile this with JDK 6 you'll need to edit the Clone.class to clear the ACC_SUPER flag. Use a hex editor to replace 20 (hex) with 00 or download a copy here.

Now run it:

C:\j>\jdk1.7-b145\bin\java Demo
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006cd5af54, pid=3708, t id=10460
#
# JRE version: 7.0-b145
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b15 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# V [jvm.dll+0x1caf54]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\j\hs_err_pid3708.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#

Thursday, 01 November 2012 16:11:20 (W. Europe Standard Time, UTC+01:00)  #    Comments [9]
# Wednesday, 31 October 2012
IKVM.NET 7.2 Release Candidate 4

Yet another release candidate.

Changes (relative to rc 3):

  • Updated version to 7.2.4630.4
  • Added (optional) support for building without System.Core.dll dependency.
  • Bug fix. Generate override stubs for unsupported abstract generic methods. Fix for #3579785.
  • Bug fix. Handle incomplete interface mappings. Fix for bug #3581564.
  • Bug fix. Verifier should not merge state from instruction following exception block to handler. Fix for bug #3580611.

Binaries available here: ikvmbin-7.2.4630.4.zip

Sources: ikvmsrc-7.2.4630.4.zip, openjdk-7u6-b24-stripped.zip

Wednesday, 31 October 2012 13:50:31 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Tuesday, 23 October 2012
IKVM.NET 7.2 Release Candidate 3

The stream of release candidates seems to never end, but I really wanted to include the fix for bug #3575555. I also included some other low-risk fixes.

Changes (relative to rc 2):

  • Updated version to 7.2.4630.3
  • Bug fix. Off-by-one error in JNI local ref index reusing. Fix for bug #3575555.
  • Bug fix. Don't try to inject DynamicMethod in array types (applies to array.clone() method for MethodHandles).
  • IKVM.Reflection: Bug fix. ModuleReader.ResolveMember() should support types. Thanks to Jb Evain for finding this.
  • IKVM.Reflection: Bug fix. While reading the Mono.Cecil source I realized that array bounds are signed.
  • IKVM.Reflection: Bug fix. LocalBuilder should extend LocalVariableInfo.
  • IKVM.Reflection: Implemented LocalVariableInfo.ToString().

Binaries available here: ikvmbin-7.2.4630.3.zip

Sources: ikvmsrc-7.2.4630.3.zip, openjdk-7u6-b24-stripped.zip

Tuesday, 23 October 2012 10:24:01 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Monday, 08 October 2012
IKVM.NET 7.2 Release Candidate 2

More bug fixes.

Changes (relative to rc 1):

  • Updated version to 7.2.4630.2
  • Bug fix. Class.forName("") should not throw System.ArgumentException.
  • Bug fix. Transient field modifier should be retained on literal fields.
  • Bug fix. Field.getModifiers() should only return the relevant modifiers.
  • IKVM.Reflection: Bug fix. Ignore unknown metadata streams.
  • IKVM.Reflection: Bug fix. Set AddressOfRawData in IMAGE_DEBUG_DIRECTORY.

Binaries available here: ikvmbin-7.2.4630.2.zip

Sources: ikvmsrc-7.2.4630.2.zip, openjdk-7u6-b24-stripped.zip

Monday, 08 October 2012 09:48:54 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, 03 October 2012
IKVM.NET 0.46 Update 2 Release Candidate 1

I forgot to include the fix for transient constant static final fields in the previous release candidate and a new bug was reported in how IKVM.Reflection writes the debug PE header that causes problems with Visual Studio 2012's code coverage tools.

Changes (relative to 0.46 Update 2 rc 0):

  • Updated version to 0.46.0.4.
  • Fixed ikvmc to retain transient modifier on constant static final fields.
  • Fixed Field.getModifiers() to only return the relevant modifiers.
  • Fixed IKVM.Reflection to set AddressOfRawData in IMAGE_DEBUG_DIRECTORY.

Binaries available here: ikvmbin-0.46.0.4.zip

Sources: ikvmsrc-0.46.0.4.zip, openjdk6-b22-stripped.zip

Wednesday, 03 October 2012 08:26:59 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Thursday, 27 September 2012
Bye Bye ConstructorBuilder

System.Reflection.Emit is a great .NET feature, especially if you consider that it shipped as part of .NET 1.0, but the design of System.Reflection.Emit leaves something to be desired.

One of the crazy features is ConstructorBuilder. On the System.Reflection side, ConstructorInfo isn't all that helpful, but it is not as actively harmful as ConstructorBuilder. The reason for this is that ConstructorInfo and MethodInfo both extend MethodBase, so most common APIs are available through MethodBase.

ConstructorBuilder and MethodBuilder share no common Builder base class (because they extend ConstructorInfo and MethodInfo), this causes a lot of code duplication and type testing/downcasting.

A long time ago I found out that you can mostly avoid ConstructorBuilder, since it is possible to use TypeBuilder.DefineMethod() to define constructors. Recently I finally got around to taking advantage of this and completely removing ConstructorBuiler from the IKVM.NET runtime and compiler.

The thing that pushed me over the edge was this experiment. In .NET 2.0 there is no ConstructorBuilder equivalent to MethodBuilder.CreateMethodBody(). So if I'm ever going to experiment with method level JIT it is nice to be able to use this more efficient method of installing the stub.

There is one problem with using MethodBuilder for constructors. If you define a custom attribute and want to apply that custom attribute while it is still unbaked, you need a ConstructorBuilder for the custom attribute constructor, because CustomAttributeBuilder requires it. Luckily, in dynamic mode IKVM doesn't need to do this and in static mode I use IKVM.Reflection so I added MethodInfo.__AsConstructorInfo() to wrap the MethodInfo in a ConstructorInfo.

I considered adding MethodInfo support to CustomAttributeBuilder, but that turned out to be much more complicated, so I went with the easy approach of reusing the existing wrapping strategy.

The result of this refactoring is the removal of a bunch of duplicate code and a lot of downcasting. It also saves a small bit of memory, because the ConstructorBuilder wrappers are not needed anymore.

Thursday, 27 September 2012 14:29:05 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, 26 September 2012
IKVM.NET 0.46 Update 2 Release Candidate 0

The 0.46 version is the last version based on Java 6 and as mentioned previously would be supported longer than a typical release. Based on user feedback I decided to post an update that fixes a number of bugs that have been found since the previous release.

Changes (relative to 0.46 Update 1):

  • Updated version to 0.46.0.3.
  • Bug fix. java.lang.Package was not populated from manifest for ikvmc compiled assemblies.
  • Bug fix. When writing a direct ByteBuffer to a non-blocking socket and the write fails because there is no kernel buffer available, we should not advance the ByteBuffer position.
  • Bug fix. When adding certificates to virtual cacerts file make sure that the aliases are unique.
  • Bug fix. If a finally/fault handler contains reachable code before the handler's start index, the handler should branch to the handler start index.
  • Bug fix. After emitting a finally/fault handler block, we should emit the block leave stubs (even though you can't leave the block, they also emit the backward branch stubs).
  • Bug fix. If a Java class extends a remapped .NET type (cli.System.Object or cli.System.Exception), we should correctly report the base class.
  • Bug fix. If we encounter a jsr or ret instruction, we should throw a VerifyError (instead of NotImplementedException).
  • Bug fix. If an exception block ends with an astore, we need to propagate the local variable type after the astore to the exception handler.
  • Disable AppDomain.ProcessExit hook to run shutdown hooks when running on Mono to workaround https://bugzilla.xamarin.com/show_bug.cgi?id=5650
  • Bug fix. Custom attribute properties that don't have a public getter and setter should not be exposed as annotation properties.
  • Bug fix. Non-public property getter/setter methods should be ignored when we create properties to hide properties inherited from shadow types. This fixes a build break with .NET 4.5 beta which introduces a protected setter for Exception.HResult.
  • Bug fix. The $Method inner class for delegates should also be loadable for generic delegates. Thanks to Michael Bayne for reporting this.
  • Bug fix. When constructing a generic class loader we can't use GetWrapperFromType() on the type arguments, because they might refer to a subtype that is currently being loaded.
  • Replaced non-ascii character (micro) with ascii 'u' in Win32PrintService.java.
  • IKVM.Reflection: Bug fix. Resource Directory Entries must be sorted and names are case-insensitive.

Binaries available here: ikvmbin-0.46.0.3.zip

Sources: ikvmsrc-0.46.0.3.zip, openjdk6-b22-stripped.zip

Wednesday, 26 September 2012 08:16:30 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Monday, 17 September 2012
IKVM.NET 7.2 Release Candidate 1

The previous release candidate had a regression that caused custom attributes specified in the remap xml file not to be applied. This caused the build to fail on .NET 4.0.

Changes (relative to rc 0):

  • Updated version to 7.2.4630.1
  • Fixed build number in CommonAssemblyInfo.cs.in.
  • Fixed .NET 4.0 build issues.
  • Fixed map.xml custom attribute application regression.
  • Updated HOWTO.

Binaries available here: ikvmbin-7.2.4630.1.zip

Sources: ikvmsrc-7.2.4630.1.zip, openjdk-7u6-b24-stripped.zip

Monday, 17 September 2012 13:39:29 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]