# Saturday, December 24, 2005
« IKVM 0.22 Released | Main | IKVM 0.24 rc1 »
Getting Incorrect Code to Run Correctly

One of the big challenges of doing a new implementation of an already existing platform is compatibility with the existing platform. Even though there is usually documentation or maybe even a specification that describes the functionality of the platform (and the things you can and cannot depend upon), in practice it turns out that much code that is written against a particular implementation will depend on implementation details. A typical response to this problem is: "That code is incorrect, because it makes assumptions that aren't guaranteed to hold."

The truth of the matter is, of course, that this issue isn't black and white. Sometimes the documentation or specification is vague or ambiguous, sometimes you need to depend on implementation details, because the documented interface simply isn't good enough or in many cases the dependency may simply be a bug in the code, but it's not always easy, desirable or even possible to fix the code.

Ultimately, when a customer has a piece of code that runs correctly on one implementation and it doesn't run on another implementation, the customer has a problem (and will in many cases assume that the problem is caused by the alternative implementation, since that's only thing that is being varied), so from a customer's point of view, supporting “incorrect” code can be a very important feature.

I've spent a lot of effort in IKVM to support incorrect code. Sometimes this can be frustrating, but I realize that the value of IKVM is to a large degree proportional to its compatibility with Java.

Some people in the GNU Classpath community think that we should implement the specification as correctly and efficiently as possible, but I'm often arguing for compatibility with the Sun implementation, even if this means duplicating buggy or inefficient behavior. Obviously this is a tricky issue, because Sun fixes bugs and sometimes makes backward compatibility breaking changes as well, so in every case we need to figure out whether it is likely that Sun will ever fix the bug (or change the implementation) and whether the benefit outweighs the cost.

It's important to always keep in mind though, that “The Right Thing” from our geeky developer oriented view doesn't always align with our customer's expectations and I think that most FOSS projects could benefit from a little bit more customer oriented thinking every now and then.

Saturday, December 24, 2005 1:01:15 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
Saturday, December 24, 2005 1:40:21 PM (W. Europe Standard Time, UTC+01:00)
Good point! And having been on the "customer" end of this problem recently I can say how much I appreciate this point of view! We're all customers of somebody so the Golden Rule[1].applies.

[1] - http://en.wikipedia.org/wiki/Ethic_of_reciprocity
Tuesday, January 3, 2006 6:32:36 PM (W. Europe Standard Time, UTC+01:00)
I agree with you. I've run up with a couple of arguments with GNU on some "unsupported" features.
The way various Map implementations implement equals in the Sun version will return true when a == b, but a.equals(b) is false.
If you clone a ThreadLocal (override the class, and implement Cloneable), then in Sun changes to the value will not change the origional, but in Classpath, changes to the origional will change the clone.

Both of these problems actually occur due to an optimization that Sun uses, that Classpath doesn't.
Artemus Harper
Tuesday, January 10, 2006 2:26:06 PM (W. Europe Standard Time, UTC+01:00)
I think so. Currently, Classpath project is ruled under formalists. Several bug reports are waited because these are SUN’s bug. I believe most of them are remained by SUN on purpose. Classpath project is only to create free Java environment, not to create new ideal virtual machine. So, incompatibility with SUN's VM is enough to try to fix it. I found some program doesn't work because of this matter.
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview