One of the bizarre things is that the method overriding behavior changed between Java 6 and Java 7 (and HotSpot preserves the Java 6 behavior for classes that have major class file version < 51), but the spec doesn't mention this at all, where it generally is pretty good about mentioning different behavior based on class file version.

Here's an example that uses a class hierarchy that mixes version 50 and 51 classes to confuse HotSpot JDK 7:

After you compile this with javac 7 (again using the trick to first compile without the public modifier on A.foo) then use a hex editor to modify p3/C.class to change the class file version from 51 (33 hex) to 50 (32 hex) at offset 7 in the file.

When you run it you get:

D.fooD.fooException in thread "main" java.lang.AbstractMethodError: p3.C.foo()V at p3.C.(C.java:5) at p4.D.(D.java:3) at p1.A.main(A.java:10)

For another example of weird JDK 7 behavior, start with the code from part 2 and make B.foo final.

When you run that you get:

C.fooB.foo

So now C.foo suddenly doesn't override B.foo. This also violates the spec, because when a method that would have been overridden is marked final the verifier should fail to load the class. This shows that the verifier and vtable layout code have different ideas about method overriding semantics.

(If you want to compile this with javac you'll need to first compile it with a version of A that does not have a public foo method and then change A and just recompile A.)

Now the question is does C.foo override B.foo? According to the spec it does not, but when you compile this with javac from JDK 7 (because the class file version needs to be 51 to get the new behavior) and run it you get:

The Java Virtual Machine Specification Java SE 7 Edition finally has a section about method overriding (5.4.5). Unfortunately, it does not document the behavior of the Java 7 reference implementation, nor the Java 6 behavior. It also turns out to be a bad design.

The frob() method is package private and you don't want external code calling it. Now a new version of the widget framework is released that adds a frob method to Widget:

package org.example;

public class Widget{ public void frob() { }}

Starting with Java 7 (and this particular behavior is defined by the spec) your package private MyWidget frob() will now override Widget.frob() and hence be callable by anyone who happens to have a reference to your object. If MyWidget.frob() does anything security critical, the third party framework has now introduced a vulnerability in your code.

Java already had a poor story for adding virtual methods to public classes, but this change has made it even worse.

Fixed the remaining known OpenJDK 7 issues, apart from method overriding, which finally made it into the JVM spec (section 5.4.5), but it's not clear yet what the actual behavior should be. It's a little ridiculous, but almost 16 years after the release of Java 1.0 a fundamental part of the JVM is still poorly documented and implemented.

Changes:

Added ikvmc -platform:arm and -platform:anycpu32bitpreferred options.

Bug fix. Make sure sun.misc.Launcher is initialized before setting a security manager, because Launcher assumes there is no security manager yet.

After the Build keynote many people were confused. I think there were three main reasons for that: 1) Metro Style Apps and Windows Runtime APIs were introduced together, 2) marketing had banned the mention of COM and 3) Windows Runtime is a bad name.

As the conference progressed and people had time to ask more questions and attend more sessions things became a bit clearer. If you haven't already done so, please read Miguel's blog entry about WinRT.

Let's dive deeper into the three points of confusion:

Metro Style Apps and Windows Runtime are two orthogonal concepts.I expect some people to take issue with this, but the reality is that Metro is a new application model and WinRT is a new way of exposing Windows APIs. They are completely orthogonal. To be clear, most new WinRT APIs are only usuable from Metro Style Apps, but that is simply a consequence of the fact that many new APIs were added to support Metro and WinRT is the obvious way to do it.It should be obvious by now, but I'll explicitly mention it. Some WinRT APIs are usable from non-Metro apps and some Win32 APIs are useable from Metro apps.

WinRT is an evolution of COM. IMO, if they had mentioned this during the keynote, there would have been a lot less confusion. However, marketing had apparently found that people don't like COM and so it was decided that this should not be mentioned, of course during subsequent talks it quickly became obvious anyway.

The Runtime in "Windows Runtime" is like the Runtime in "C runtime library", not like the Runtime in "Common Language Runtime". The Windows Runtime is not an execution environment, just a set of APIs and a way of exposing these APIs (and your own APIs using a similar mechanism).

What About .NET?

Like COM, Windows Runtime APIs can be used from different languages (but the language needs to do some work to enable this). Microsoft supports using WinRT APIs from C/C++, Javascript and C#/VB. All of these languages were modified to support this. Not all .NET languages automatically get full support for WinRT, for example there is currently no first class WinRT support in F#.

Some people thought that .NET was going to be replaced by WinRT (probably due to reason 3 above), but this clearly doesn't make sense.

Something of interest from a .NET point of view is that instead of type libraries WinRT uses the .NET (ECMA CLI) metadata format to describe the APIs. I made a couple of minor tweaks to IKVM.Reflection to better support this.

What About IKVM.NET?

I have not yet investigated exactly what is needed for WinRT support in IKVM.NET, but it is very likely that WinRT support will arrive some time before Windows 8 is released.

Note however that running IKVM.NET inside Metro Style Apps will not be supported, because the .NET Metro profile is very limited. Hopefully more about this in a future blog entry.

The release notes for IKVM.NET have always said "Not implemented" for java.lang.management and javax.management. This was mostly due to the fact that I don't know very much about this area of Java and it doesn't make a lot of sense to use Java management tools when the equivalent .NET management tools are probably a better fit (at least for VM level operations).

This week, prompted by a question on the ikvm-developers list, I decided to look into improving the situation (a bit). As a result it is now possible to get the platform MBean server and to connect to it with the jconsole application.

Now when you start jconsole in the following way, you can connect to localhost:9999

jconsole -J-Dcom.sun.management.jmxremote.ssl=false

Note that the mechanism that jconsole uses to detect and connect to locally running JDK instances is very platform specific and is not supported. Note also that IKVM does not support "agents" , so you have to start the management agent explicitly by calling it directly.

Limitations

The information (and operations) exposed is pretty limited. I still maintain that using .NET specific management tools is a better solution, but if you have any specific scenario you want to see supported, please let me know and I'll consider it.