# Monday, April 23, 2007
« Running Application Test Suites | Main | IKVM 0.34 rc1 »
JCK Certification

Dan Diephouse wrote in the comments to the previous entry:

Thats some serious comment spam thwarter - I had to look up the answer! Might I suggest Askimet? It rocks.

Yeah, sorry about that. That was mainly driven by ease of implementation. The fixed question was very easy to add in the aspx page without having to do any thinking on my part. The most amazing part is that a spammer actually managed to get through a couple of weeks ago.

Anyway, was wondering, do you think IKVM could ever become a certified java run time? (provided Sun made the JCK available under a reasonable license)

Funny you should ask, because I was thinking about blogging about this question yesterday (inspired by the Apache open letter and Mark Wielaard's and Dalibor Topic's responses).

The short answer is that it's not my goal for IKVM to be a certified Java runtime. I do not have access to the JCK, but it is my understanding that adding extra functionality is not allowed. Since IKVM runs on .NET it makes sense to expose .NET functionality (like for example delegates and P/Invoke). Remember that when Microsoft added delegates and J/Direct (which is the predecessor to P/Invoke) to its JVM they got sued by Sun for violating their license agreement.

There are also other issues that make a fully compliant version of IKVM only of theoretical interest. The floating point performance would be pretty bad, for example. Currently, the floating point support uses the native .NET floating point operations, but those are too relaxed for the JVM specification (mostly because they use too much precision). Another example: If you wanted static initializers to work according to the JVM spec (i.e. deadlock in certain scenarios), that would make them less efficient and would hinder interop with .NET code. One more: Because CharSequence is a ghost interface, when you do new CharSequence[] you really get an Object[], again it's possible to hide this from Java code, but it would make all object array access very slow.

Finally, there is one thing that I really don't know how to implement (in the current architecture). In Java it is possible for JNI code to allocate a string object and then later on call the constructor on it (or even to call the constructor twice), because .NET strings are variable size objects and require that the contents be specified at allocation time this is impossible to implement on IKVM.

Monday, April 23, 2007 8:54:34 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [4]
Monday, April 23, 2007 6:19:49 PM (W. Europe Daylight Time, UTC+02:00)
Very interesting - thanks for the response!
Wednesday, May 9, 2007 9:48:11 AM (W. Europe Daylight Time, UTC+02:00)
I only just noticed this: I thought the JVM spec only required the exact, specified level of precision to be used in floating point when the "strictfp" modifier is used. Otherwise I thought that using extra precision for performance reasons (usually due to hardware support) was legal...
Wednesday, May 9, 2007 10:05:26 AM (W. Europe Daylight Time, UTC+02:00)
Even without strictfp, the Java fp rules are a little bit tighter than the .NET rules.
Sunday, February 3, 2008 6:42:28 AM (W. Europe Standard Time, UTC+01:00)
Reading this, I have a couple of thoughts. The first is in regard to your statement "but it is my understanding that adding extra functionality is not allowed."

I don't think Sun or their license agreements have any problem with adding additional functionality per-se, so long as you put your additional functionality in your own packages. Its only when you add your functionality to the java.* packages that you run in to trouble with them. And I suspect that was the problem Microsoft had -- the issue was not so much that Microsoft had added their own proprietary features to the Java platform (every vendor does that!), but the way in which they had chosen to add those features.

The second is that, in the areas where it is not possible for IKVM to be 100% Java compatible due to limitations of the CLR -- I wonder how hard it would be to extend the CLR to enable 100% compatibility? For example, if there is no (performant) way to do Java-compliant FP with the CLR, maybe the CLR could be extended to support a Java-compatible FP mode? Maybe hard with .Net (would need MS involvement, and I don't know how interested MS would be in that...), but might be possible with Mono.... And the same comments would apply to the other limitations of the CLR you mentioned....

Still, all this awaits Sun to release the JCK under terms more friendly to open source, if they ever do.....
Comments are closed.