A new development snapshot is available. I finished the merge of JSR-292 part of OpenJDK 7u40. The result is a bit depressing (but not unexpected) for the amount of effort that it took. The net result is that most stuff works the same (I did fix a couple of bugs), except slower.

I expect that eventually I'll get around to optimizing things a bit, but for now I've spent enough time on it to want to work on something else.

Bug fix. If CLASSGC is enabled, we should use a WeakReference to cache the MethodType for the MethodHandle.invoke() cache.

Bug fix. MethodHandle.invoke() cache should consider vararg-ness of the MethodHandle.

Removed HideFromReflectionAttribute.

Added flags to HideFromJavaAttribute to support different levels of hiding (including the previous usage of HideFromReflectionAttribute and adding specific ability to hide from security stack walking and from stack traces, for future LamdbaForm support).

IKVM.Reflection: Added the 4.5 (reference) assemblies to the framework list. The previous assumption was that we only need to add assemblies for previous frameworks, but that turns out to be incorrect because the list affects CompareAssemblyIdentity() which returns EquivalentFXUnified for framework assemblies.

IKVM.Reflection: ProcessorArchitecture should be read from flags and not its own field. This fixes the bug that GetReferencedAssemblies() did not return the ProcessorArchitecture part of the assembly flags.

IKVM.Reflection: Fixed assembly reference resolution issues (Name was not escape, Retargetable and ContentType attributes were not added, PublicKey was not converted to PublicKeyToken).

IKVM.Reflection: When a cyclic type forwarder is found and UniverseOptions.ResolveMissingMembers is set, we should not throw an exception but instead create a missing type. Added a new Type.__IsCyclicTypeForwarder property to allow detecting this case.

IKVM.Reflection: Bug fix. Assembly may contain both PublicKeyToken and PublicKey if they are the same identity.

This makes no sense at all and is a misguided attempt to fix the issue I reported here. Ironically, it doesn't even completely fix the issue, because a static finalize method still prevents the final finalizer from running:

You can compile and run this without Indify and it will show the problem (on versions before Update 21), but you need to run Indify to make it work with an active SecurityManager.

The difference between looking up method handles via the API versus using MethodHandle constants is analogous to the difference between normal bytecode method invocation and classic reflection. When going via the API the SecurityManager is involved, but the runtime linker does not call the SecurityManager. MethodHandle constants (when they are properly implemented) don't allow you to do anything that normal bytecode can't do. This is why the claim made by Security Explorations about Issue 54 was incorrect.

While I was working on rewriting IKVM's dynamic binding support based on method handles I stumbled into a rather serious bug in the Oracle Java implementation. It allowed any code to overwrite public final fields. This has been fixed in Update 21.

Below is a proof of concept that disables the security manager. It works by changing Double.TYPE to Integer.TYPE and then using reflection to copy an integer field from one object to another, but because of the patched TYPE fields reflection thinks the integer field is a double and copies 8 bytes instead of 4.